date:20210707

== Series Details ==

Series: Minor revid/stepping and workaround cleanup
URL   : https://patchwork.freedesktop.org/series/92299/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Minor revid/stepping and workaround cleanup

== Series Details ==

Series: Minor revid/stepping and workaround cleanup
URL   : https://patchwork.freedesktop.org/series/92299/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
76c5a033ed04 drm/i915: Make pre-production detection use direct revid comparison
c88cee5325fe drm/i915/skl: Use revid->stepping tables
-:54: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#54: FILE: drivers/gpu/drm/i915/i915_drv.h:1450:
+#define IS_SKL_GT_STEP(p, since, until) (IS_SKYLAKE(p) && IS_GT_STEP(p, since, 
until))

total: 0 errors, 0 warnings, 1 checks, 85 lines checked
4f8fb265f095 drm/i915/icl: Use revid->stepping tables
-:93: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#93: FILE: drivers/gpu/drm/i915/i915_drv.h:1457:
+#define IS_ICL_GT_STEP(p, since, until) \
+   (IS_ICELAKE(p) && IS_GT_STEP(p, since, until))

total: 0 errors, 0 warnings, 1 checks, 94 lines checked
46752176291f drm/i915/jsl_ehl: Use revid->stepping tables
-:51: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#51: FILE: drivers/gpu/drm/i915/i915_drv.h:1460:
+#define IS_JSL_EHL_GT_STEP(p, since, until) \
+   (IS_JSL_EHL(p) && IS_GT_STEP(p, since, until))

-:53: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#53: FILE: drivers/gpu/drm/i915/i915_drv.h:1462:
+#define IS_JSL_EHL_DISPLAY_STEP(p, since, until) \
+   (IS_JSL_EHL(p) && IS_DISPLAY_STEP(p, since, until))

total: 0 errors, 0 warnings, 2 checks, 51 lines checked
54dfa2be0428 drm/i915/rkl: Use revid->stepping tables
-:48: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#48: FILE: drivers/gpu/drm/i915/i915_drv.h:1477:
+#define IS_RKL_DISPLAY_STEP(p, since, until) \
+   (IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until))

total: 0 errors, 0 warnings, 1 checks, 51 lines checked
9e913fff5691 drm/i915/dg1: Use revid->stepping tables
-:124: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#124: FILE: drivers/gpu/drm/i915/i915_drv.h:1471:
+#define IS_DG1_GT_STEP(p, since, until) \
+   (IS_DG1(p) && IS_GT_STEP(p, since, until))

-:126: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#126: FILE: drivers/gpu/drm/i915/i915_drv.h:1473:
+#define IS_DG1_DISPLAY_STEP(p, since, until) \
+   (IS_DG1(p) && IS_DISPLAY_STEP(p, since, until))

total: 0 errors, 0 warnings, 2 checks, 118 lines checked
c78151696795 drm/i915/cnl: Drop all workarounds


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/7] drm/i915/dg1: Use revid->stepping tables

Switch DG1 to use a revid->stepping table as we're trying to do on all
platforms going forward.

This removes the last use of IS_REVID() and REVID_FOREVER, so remove
those now-unused macros as well to prevent their accidental use on
future platforms.

Bspec: 44463
Signed-off-by: Matt Roper 
---
 .../gpu/drm/i915/display/intel_display_power.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c|  2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c| 10 +-
 drivers/gpu/drm/i915/i915_drv.h| 18 --
 drivers/gpu/drm/i915/intel_pm.c|  2 +-
 drivers/gpu/drm/i915/intel_step.c  |  8 
 6 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 285380079aab..975a7e25cea5 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5799,7 +5799,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private 
*dev_priv)
int config, i;
 
if (IS_ALDERLAKE_S(dev_priv) ||
-   IS_DG1_REVID(dev_priv, DG1_REVID_A0, DG1_REVID_A0) ||
+   IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
/* Wa_1409767108:tgl,dg1,adl-s */
table = wa_1409767108_buddy_page_masks;
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 1f43aba2e9e2..50d11a84e7a9 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -157,7 +157,7 @@ intel_gt_setup_fake_lmem(struct intel_gt *gt)
 static bool get_legacy_lowmem_region(struct intel_uncore *uncore,
 u64 *start, u32 *size)
 {
-   if (!IS_DG1_REVID(uncore->i915, DG1_REVID_A0, DG1_REVID_B0))
+   if (!IS_DG1_GT_STEP(uncore->i915, STEP_A0, STEP_B0))
return false;
 
*start = 0;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 4c0c15bbdac2..62321e9149db 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -,7 +,7 @@ dg1_gt_workarounds_init(struct drm_i915_private *i915, 
struct i915_wa_list *wal)
gen12_gt_workarounds_init(i915, wal);
 
/* Wa_1607087056:dg1 */
-   if (IS_DG1_REVID(i915, DG1_REVID_A0, DG1_REVID_A0))
+   if (IS_DG1_GT_STEP(i915, STEP_A0, STEP_A0))
wa_write_or(wal,
SLICE_UNIT_LEVEL_CLKGATE,
L3_CLKGATE_DIS | L3_CR2X_CLKGATE_DIS);
@@ -1522,7 +1522,7 @@ static void dg1_whitelist_build(struct intel_engine_cs 
*engine)
tgl_whitelist_build(engine);
 
/* GEN:BUG:1409280441:dg1 */
-   if (IS_DG1_REVID(engine->i915, DG1_REVID_A0, DG1_REVID_A0) &&
+   if (IS_DG1_GT_STEP(engine->i915, STEP_A0, STEP_A0) &&
(engine->class == RENDER_CLASS ||
 engine->class == COPY_ENGINE_CLASS))
whitelist_reg_ext(w, RING_ID(engine->mmio_base),
@@ -1592,7 +1592,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct 
i915_wa_list *wal)
 {
struct drm_i915_private *i915 = engine->i915;
 
-   if (IS_DG1_REVID(i915, DG1_REVID_A0, DG1_REVID_A0) ||
+   if (IS_DG1_GT_STEP(i915, STEP_A0, STEP_A0) ||
IS_TGL_UY_GT_STEP(i915, STEP_A0, STEP_A0)) {
/*
 * Wa_1607138336:tgl[a0],dg1[a0]
@@ -1638,7 +1638,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct 
i915_wa_list *wal)
}
 
if (IS_ALDERLAKE_P(i915) || IS_ALDERLAKE_S(i915) ||
-   IS_DG1_REVID(i915, DG1_REVID_A0, DG1_REVID_A0) ||
+   IS_DG1_GT_STEP(i915, STEP_A0, STEP_A0) ||
IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
/* Wa_1409804808:tgl,rkl,dg1[a0],adl-s,adl-p */
wa_masked_en(wal, GEN7_ROW_CHICKEN2,
@@ -1652,7 +1652,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct 
i915_wa_list *wal)
}
 
 
-   if (IS_DG1_REVID(i915, DG1_REVID_A0, DG1_REVID_A0) ||
+   if (IS_DG1_GT_STEP(i915, STEP_A0, STEP_A0) ||
IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
/*
 * Wa_1607030317:tgl
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6de2590afff6..1c6a73044c67 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1270,19 +1270,10 @@ static inline struct drm_i915_private 
*pdev_to_i915(struct pci_dev *pdev)
 #define IS_DISPLAY_VER(i915, from, until) \
(DISPLAY_VER(i915) >= (from) && DISPLAY_VER(i915) <= (until))
 
-#define REVID_FOREVER  0xff
 #define INTEL_REVID(dev_priv)  (to_pci_dev((dev_priv)->drm.dev)->revision)
 
 #define HAS_DSB(dev_priv)

[Intel-gfx] [PATCH 5/7] drm/i915/rkl: Use revid->stepping tables

Switch RKL to use a revid->stepping table as we're trying to do on all
platforms going forward.

Bspec: 44501
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
 drivers/gpu/drm/i915/i915_drv.h  | 8 ++--
 drivers/gpu/drm/i915/intel_step.c| 9 +
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 9643624fe160..74b2aa3c2946 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -594,7 +594,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
if (intel_dp->psr.psr2_sel_fetch_enabled) {
/* WA 1408330847 */
if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
-   IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
+   IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
 DIS_RAM_BYPASS_PSR2_MAN_TRACK,
 DIS_RAM_BYPASS_PSR2_MAN_TRACK);
@@ -1342,7 +1342,7 @@ static void intel_psr_disable_locked(struct intel_dp 
*intel_dp)
/* WA 1408330847 */
if (intel_dp->psr.psr2_sel_fetch_enabled &&
(IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
-IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
+IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0)))
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
 DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3f4e17ba5e80..6de2590afff6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1489,12 +1489,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
(IS_TIGERLAKE(__i915) && !(IS_TGL_U(__i915) || IS_TGL_Y(__i915)) && \
 IS_GT_STEP(__i915, since, until))
 
-#define RKL_REVID_A0   0x0
-#define RKL_REVID_B0   0x1
-#define RKL_REVID_C0   0x4
-
-#define IS_RKL_REVID(p, since, until) \
-   (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
+#define IS_RKL_DISPLAY_STEP(p, since, until) \
+   (IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until))
 
 #define DG1_REVID_A0   0x0
 #define DG1_REVID_B0   0x1
diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index 61666a3dd672..1593ab25f41a 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -69,6 +69,12 @@ static const struct intel_step_info tgl_revid_step_tbl[] = {
[1] = { .gt_step = STEP_B0, .display_step = STEP_D0 },
 };
 
+static const struct intel_step_info rkl_revid_step_tbl[] = {
+   [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
+   [1] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
+   [4] = { .gt_step = STEP_C0, .display_step = STEP_C0 },
+};
+
 static const struct intel_step_info adls_revid_step_tbl[] = {
[0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
[0x1] = { .gt_step = STEP_A0, .display_step = STEP_A2 },
@@ -97,6 +103,9 @@ void intel_step_init(struct drm_i915_private *i915)
} else if (IS_ALDERLAKE_S(i915)) {
revids = adls_revid_step_tbl;
size = ARRAY_SIZE(adls_revid_step_tbl);
+   } else if (IS_ROCKETLAKE(i915)) {
+   revids = rkl_revid_step_tbl;
+   size = ARRAY_SIZE(rkl_revid_step_tbl);
} else if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
revids = tgl_uy_revid_step_tbl;
size = ARRAY_SIZE(tgl_uy_revid_step_tbl);
-- 
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 7/7] drm/i915/cnl: Drop all workarounds

All of the Cannon Lake hardware that came out had graphics fused off,
and our userspace drivers have already dropped their support for the
platform; CNL-specific code in i915 that isn't inherited by subsequent
platforms is effectively dead code.  Let's remove all of the
CNL-specific workarounds as a quick and easy first step.

References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6899
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 55 -
 1 file changed, 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 62321e9149db..9b257a394305 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -514,35 +514,6 @@ static void cfl_ctx_workarounds_init(struct 
intel_engine_cs *engine,
 GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
 }
 
-static void cnl_ctx_workarounds_init(struct intel_engine_cs *engine,
-struct i915_wa_list *wal)
-{
-   /* WaForceContextSaveRestoreNonCoherent:cnl */
-   wa_masked_en(wal, CNL_HDC_CHICKEN0,
-HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT);
-
-   /* WaDisableReplayBufferBankArbitrationOptimization:cnl */
-   wa_masked_en(wal, COMMON_SLICE_CHICKEN2,
-GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
-
-   /* WaPushConstantDereferenceHoldDisable:cnl */
-   wa_masked_en(wal, GEN7_ROW_CHICKEN2, PUSH_CONSTANT_DEREF_DISABLE);
-
-   /* FtrEnableFastAnisoL1BankingFix:cnl */
-   wa_masked_en(wal, HALF_SLICE_CHICKEN3, CNL_FAST_ANISO_L1_BANKING_FIX);
-
-   /* WaDisable3DMidCmdPreemption:cnl */
-   wa_masked_dis(wal, GEN8_CS_CHICKEN1, GEN9_PREEMPT_3D_OBJECT_LEVEL);
-
-   /* WaDisableGPGPUMidCmdPreemption:cnl */
-   wa_masked_field_set(wal, GEN8_CS_CHICKEN1,
-   GEN9_PREEMPT_GPGPU_LEVEL_MASK,
-   GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
-
-   /* WaDisableEarlyEOT:cnl */
-   wa_masked_en(wal, GEN8_ROW_CHICKEN, DISABLE_EARLY_EOT);
-}
-
 static void icl_ctx_workarounds_init(struct intel_engine_cs *engine,
 struct i915_wa_list *wal)
 {
@@ -704,8 +675,6 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
gen12_ctx_workarounds_init(engine, wal);
else if (GRAPHICS_VER(i915) == 11)
icl_ctx_workarounds_init(engine, wal);
-   else if (IS_CANNONLAKE(i915))
-   cnl_ctx_workarounds_init(engine, wal);
else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915))
cfl_ctx_workarounds_init(engine, wal);
else if (IS_GEMINILAKE(i915))
@@ -982,15 +951,6 @@ icl_wa_init_mcr(struct drm_i915_private *i915, struct 
i915_wa_list *wal)
wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr);
 }
 
-static void
-cnl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list 
*wal)
-{
-   /* WaInPlaceDecompressionHang:cnl */
-   wa_write_or(wal,
-   GEN9_GAMT_ECO_REG_RW_IA,
-   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
-}
-
 static void
 icl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list 
*wal)
 {
@@ -1140,8 +1100,6 @@ gt_init_workarounds(struct drm_i915_private *i915, struct 
i915_wa_list *wal)
gen12_gt_workarounds_init(i915, wal);
else if (GRAPHICS_VER(i915) == 11)
icl_gt_workarounds_init(i915, wal);
-   else if (IS_CANNONLAKE(i915))
-   cnl_gt_workarounds_init(i915, wal);
else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915))
cfl_gt_workarounds_init(i915, wal);
else if (IS_GEMINILAKE(i915))
@@ -1418,17 +1376,6 @@ static void cml_whitelist_build(struct intel_engine_cs 
*engine)
cfl_whitelist_build(engine);
 }
 
-static void cnl_whitelist_build(struct intel_engine_cs *engine)
-{
-   struct i915_wa_list *w = >whitelist;
-
-   if (engine->class != RENDER_CLASS)
-   return;
-
-   /* WaEnablePreemptionGranularityControlByUMD:cnl */
-   whitelist_reg(w, GEN8_CS_CHICKEN1);
-}
-
 static void icl_whitelist_build(struct intel_engine_cs *engine)
 {
struct i915_wa_list *w = >whitelist;
@@ -1542,8 +1489,6 @@ void intel_engine_init_whitelist(struct intel_engine_cs 
*engine)
tgl_whitelist_build(engine);
else if (GRAPHICS_VER(i915) == 11)
icl_whitelist_build(engine);
-   else if (IS_CANNONLAKE(i915))
-   cnl_whitelist_build(engine);
else if (IS_COMETLAKE(i915))
cml_whitelist_build(engine);
else if (IS_COFFEELAKE(i915))
-- 
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/7] Minor revid/stepping and workaround cleanup

PCI revision IDs don't always map to GT and display IP steppings in an
intuitive/sensible way.  On many of our recent platforms we've switched
to using revid->stepping lookup tables with the infrastructure in
intel_step.c to handle stepping lookups and comparisons.  Since it's
confusing to have some of our platforms using the new lookup tables and
some still using old revid comparisons, let's migrate all the old
platforms over to the table approach since that's what we want to
standardize on going forward.  The only place that revision ID's should
really get used directly now is when checking to see if we're running on
pre-production hardware.

Let's also take the opportunity to drop a bit of effectively dead code
in the workarounds file too.

Cc: Jani Nikula 

Matt Roper (7):
  drm/i915: Make pre-production detection use direct revid comparison
  drm/i915/skl: Use revid->stepping tables
  drm/i915/icl: Use revid->stepping tables
  drm/i915/jsl_ehl: Use revid->stepping tables
  drm/i915/rkl: Use revid->stepping tables
  drm/i915/dg1: Use revid->stepping tables
  drm/i915/cnl: Drop all workarounds

 .../drm/i915/display/intel_display_power.c|  2 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  2 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  4 +-
 drivers/gpu/drm/i915/gt/intel_region_lmem.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 81 +++
 drivers/gpu/drm/i915/i915_drv.c   |  8 +-
 drivers/gpu/drm/i915/i915_drv.h   | 80 +++---
 drivers/gpu/drm/i915/intel_pm.c   |  2 +-
 drivers/gpu/drm/i915/intel_step.c | 72 +++--
 drivers/gpu/drm/i915/intel_step.h |  7 ++
 10 files changed, 107 insertions(+), 153 deletions(-)

-- 
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/7] drm/i915/icl: Use revid->stepping tables

Switch ICL to use a revid->stepping table as we're trying to do on all
platforms going forward.  While we're at it, let's include some
additional steppings that have popped up, even if we don't yet have any
workarounds tied to those steppings (we probably need to audit our
workaround list soon to see if any of the bounds have moved or if new
workarounds have appeared).

Note that the current bspec table is missing information about how to
map PCI revision ID to GT/display steppings; it only provides an SoC
stepping.  The mapping to GT/display steppings (which aren't always the
same as the SoC stepping) used to be in the bspec, but was apparently
dropped during an update in Nov 2019; I've made my changes here based on
an older bspec snapshot that still had the necessary information.  We've
requested that the missing information be restored.

Bspec: 21441  # pre-Nov 2019 snapshot
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 ++--
 drivers/gpu/drm/i915/i915_drv.h | 10 ++
 drivers/gpu/drm/i915/intel_step.c   | 12 
 drivers/gpu/drm/i915/intel_step.h   |  2 ++
 4 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 6dfd564e078f..e2d8acb8c1c9 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -557,7 +557,7 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs 
*engine,
/* Wa_1604370585:icl (pre-prod)
 * Formerly known as WaPushConstantDereferenceHoldDisable
 */
-   if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_B0))
+   if (IS_ICL_GT_STEP(i915, STEP_A0, STEP_B0))
wa_masked_en(wal, GEN7_ROW_CHICKEN2,
 PUSH_CONSTANT_DEREF_DISABLE);
 
@@ -573,12 +573,12 @@ static void icl_ctx_workarounds_init(struct 
intel_engine_cs *engine,
/* Wa_2006611047:icl (pre-prod)
 * Formerly known as WaDisableImprovedTdlClkGating
 */
-   if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_A0))
+   if (IS_ICL_GT_STEP(i915, STEP_A0, STEP_A0))
wa_masked_en(wal, GEN7_ROW_CHICKEN2,
 GEN11_TDL_CLOCK_GATING_FIX_DISABLE);
 
/* Wa_2006665173:icl (pre-prod) */
-   if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_A0))
+   if (IS_ICL_GT_STEP(i915, STEP_A0, STEP_A0))
wa_masked_en(wal, GEN11_COMMON_SLICE_CHICKEN3,
 GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC);
 
@@ -1023,13 +1023,13 @@ icl_gt_workarounds_init(struct drm_i915_private *i915, 
struct i915_wa_list *wal)
GAMW_ECO_DEV_CTX_RELOAD_DISABLE);
 
/* Wa_1405779004:icl (pre-prod) */
-   if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_A0))
+   if (IS_ICL_GT_STEP(i915, STEP_A0, STEP_A0))
wa_write_or(wal,
SLICE_UNIT_LEVEL_CLKGATE,
MSCUNIT_CLKGATE_DIS);
 
/* Wa_1406838659:icl (pre-prod) */
-   if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_B0))
+   if (IS_ICL_GT_STEP(i915, STEP_A0, STEP_B0))
wa_write_or(wal,
INF_UNIT_LEVEL_CLKGATE,
CGPSF_CLKGATE_DIS);
@@ -1725,7 +1725,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct 
i915_wa_list *wal)
PMFLUSHDONE_LNEBLK);
 
/* Wa_1406609255:icl (pre-prod) */
-   if (IS_ICL_REVID(i915, ICL_REVID_A0, ICL_REVID_B0))
+   if (IS_ICL_GT_STEP(i915, STEP_A0, STEP_B0))
wa_write_or(wal,
GEN7_SARCHKMD,
GEN7_DISABLE_DEMAND_PREFETCH);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 300575f64ca6..63cbc9991cb9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1469,14 +1469,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_KBL_DISPLAY_STEP(dev_priv, since, until) \
(IS_KABYLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, since, until))
 
-#define ICL_REVID_A0   0x0
-#define ICL_REVID_A2   0x1
-#define ICL_REVID_B0   0x3
-#define ICL_REVID_B2   0x4
-#define ICL_REVID_C0   0x5
-
-#define IS_ICL_REVID(p, since, until) \
-   (IS_ICELAKE(p) && IS_REVID(p, since, until))
+#define IS_ICL_GT_STEP(p, since, until) \
+   (IS_ICELAKE(p) && IS_GT_STEP(p, since, until))
 
 #define EHL_REVID_A00x0
 #define EHL_REVID_B00x1
diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index bfd63f56c200..4d8248cf67d3 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -42,6 +42,15 @@ static const struct intel_step_info kbl_revid_step_tbl[] = {
[7] =

[Intel-gfx] [PATCH 4/7] drm/i915/jsl_ehl: Use revid->stepping tables

Switch JSL/EHL to use a revid->stepping table as we're trying to do on
all platforms going forward.

Bspec: 29153
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 9 -
 drivers/gpu/drm/i915/intel_step.c | 8 
 4 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 882bfd499e55..dfc31b682848 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -2674,7 +2674,7 @@ static bool
 ehl_combo_pll_div_frac_wa_needed(struct drm_i915_private *i915)
 {
return ((IS_PLATFORM(i915, INTEL_ELKHARTLAKE) &&
-IS_JSL_EHL_REVID(i915, EHL_REVID_B0, REVID_FOREVER)) ||
+IS_JSL_EHL_DISPLAY_STEP(i915, STEP_B0, STEP_FOREVER)) ||
 IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) &&
 i915->dpll.ref_clks.nssc == 38400;
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index e2d8acb8c1c9..4c0c15bbdac2 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1043,7 +1043,7 @@ icl_gt_workarounds_init(struct drm_i915_private *i915, 
struct i915_wa_list *wal)
 
/* Wa_1607087056:icl,ehl,jsl */
if (IS_ICELAKE(i915) ||
-   IS_JSL_EHL_REVID(i915, EHL_REVID_A0, EHL_REVID_A0))
+   IS_JSL_EHL_GT_STEP(i915, STEP_A0, STEP_A0))
wa_write_or(wal,
SLICE_UNIT_LEVEL_CLKGATE,
L3_CLKGATE_DIS | L3_CR2X_CLKGATE_DIS);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 63cbc9991cb9..3f4e17ba5e80 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1472,11 +1472,10 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_ICL_GT_STEP(p, since, until) \
(IS_ICELAKE(p) && IS_GT_STEP(p, since, until))
 
-#define EHL_REVID_A00x0
-#define EHL_REVID_B00x1
-
-#define IS_JSL_EHL_REVID(p, since, until) \
-   (IS_JSL_EHL(p) && IS_REVID(p, since, until))
+#define IS_JSL_EHL_GT_STEP(p, since, until) \
+   (IS_JSL_EHL(p) && IS_GT_STEP(p, since, until))
+#define IS_JSL_EHL_DISPLAY_STEP(p, since, until) \
+   (IS_JSL_EHL(p) && IS_DISPLAY_STEP(p, since, until))
 
 #define IS_TGL_DISPLAY_STEP(__i915, since, until) \
(IS_TIGERLAKE(__i915) && \
diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index 4d8248cf67d3..61666a3dd672 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -51,6 +51,11 @@ static const struct intel_step_info icl_revid_step_tbl[] = {
[7] = { .gt_step = STEP_D0, .display_step = STEP_D0 },
 };
 
+static const struct intel_step_info jsl_ehl_revid_step_tbl[] = {
+   [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
+   [1] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
+};
+
 static const struct intel_step_info tgl_uy_revid_step_tbl[] = {
[0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
[1] = { .gt_step = STEP_B0, .display_step = STEP_C0 },
@@ -98,6 +103,9 @@ void intel_step_init(struct drm_i915_private *i915)
} else if (IS_TIGERLAKE(i915)) {
revids = tgl_revid_step_tbl;
size = ARRAY_SIZE(tgl_revid_step_tbl);
+   } else if (IS_JSL_EHL(i915)) {
+   revids = jsl_ehl_revid_step_tbl;
+   size = ARRAY_SIZE(jsl_ehl_revid_step_tbl);
} else if (IS_ICELAKE(i915)) {
revids = icl_revid_step_tbl;
size = ARRAY_SIZE(icl_revid_step_tbl);
-- 
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/7] drm/i915/skl: Use revid->stepping tables

Switch SKL to use a revid->stepping table as we're trying to do on all
platforms going forward.  Also add some additional stepping definitions
for completeness, even if we don't have any workarounds tied to them.

Note that SKL has a case where a newer revision ID corresponds to an
older GT/disp stepping (0x9 -> STEP_J0, 0xA -> STEP_I1).  Also, the lack
of a revision ID 0x8 in the table is intentional and not an oversight.
We'll re-write the KBL-specific comment to make it clear that these kind
of quirks are expected.

Finally, since we're already touching the KBL area too, let's rename the
KBL table to match the naming convention used by all of the other
platforms.

Bspec: 13626
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h | 11 +--
 drivers/gpu/drm/i915/intel_step.c   | 35 -
 drivers/gpu/drm/i915/intel_step.h   |  4 +++
 4 files changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index d9a5a445ceec..6dfd564e078f 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -883,7 +883,7 @@ skl_gt_workarounds_init(struct drm_i915_private *i915, 
struct i915_wa_list *wal)
GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
 
/* WaInPlaceDecompressionHang:skl */
-   if (IS_SKL_REVID(i915, SKL_REVID_H0, REVID_FOREVER))
+   if (IS_SKL_GT_STEP(i915, STEP_H0, STEP_FOREVER))
wa_write_or(wal,
GEN9_GAMT_ECO_REG_RW_IA,
GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 796e6838bc79..300575f64ca6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1462,16 +1462,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_TGL_Y(dev_priv) \
IS_SUBPLATFORM(dev_priv, INTEL_TIGERLAKE, INTEL_SUBPLATFORM_ULX)
 
-#define SKL_REVID_A0   0x0
-#define SKL_REVID_B0   0x1
-#define SKL_REVID_C0   0x2
-#define SKL_REVID_D0   0x3
-#define SKL_REVID_E0   0x4
-#define SKL_REVID_F0   0x5
-#define SKL_REVID_G0   0x6
-#define SKL_REVID_H0   0x7
-
-#define IS_SKL_REVID(p, since, until) (IS_SKYLAKE(p) && IS_REVID(p, since, 
until))
+#define IS_SKL_GT_STEP(p, since, until) (IS_SKYLAKE(p) && IS_GT_STEP(p, since, 
until))
 
 #define IS_KBL_GT_STEP(dev_priv, since, until) \
(IS_KABYLAKE(dev_priv) && IS_GT_STEP(dev_priv, since, until))
diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index ba9479a67521..bfd63f56c200 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -7,15 +7,31 @@
 #include "intel_step.h"
 
 /*
- * KBL revision ID ordering is bizarre; higher revision ID's map to lower
- * steppings in some cases.  So rather than test against the revision ID
- * directly, let's map that into our own range of increasing ID's that we
- * can test against in a regular manner.
+ * Some platforms have unusual ways of mapping PCI revision ID to GT/display
+ * steppings.  E.g., in some cases a higher PCI revision may translate to a
+ * lower stepping of the GT and/or display IP.  This file provides lookup
+ * tables to map the PCI revision into a standard set of stepping values that
+ * can be compared numerically.
+ *
+ * Also note that some revisions/steppings may have been set aside as
+ * placeholders but never materialized in real hardware; in those cases there
+ * may be jumps in the revision IDs or stepping values in the tables below.
  */
 
+static const struct intel_step_info skl_revid_step_tbl[] = {
+   [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
+   [0x1] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
+   [0x2] = { .gt_step = STEP_C0, .display_step = STEP_C0 },
+   [0x3] = { .gt_step = STEP_D0, .display_step = STEP_D0 },
+   [0x4] = { .gt_step = STEP_E0, .display_step = STEP_E0 },
+   [0x5] = { .gt_step = STEP_F0, .display_step = STEP_F0 },
+   [0x6] = { .gt_step = STEP_G0, .display_step = STEP_G0 },
+   [0x7] = { .gt_step = STEP_H0, .display_step = STEP_H0 },
+   [0x9] = { .gt_step = STEP_J0, .display_step = STEP_J0 },
+   [0xA] = { .gt_step = STEP_I1, .display_step = STEP_I1 },
+};
 
-/* FIXME: what about REVID_E0 */
-static const struct intel_step_info kbl_revids[] = {
+static const struct intel_step_info kbl_revid_step_tbl[] = {
[0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
[1] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
[2] = { .gt_step = STEP_C0, .display_step = STEP_B0 },
@@ -74,8 +90,11 @@ void intel_step_init(struct drm_i915_private *i915)
revids = tgl_revid_step_tbl;
size =

[Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production detection use direct revid comparison

Although we're converting our workarounds to use a revid->stepping
lookup table, the function that detects pre-production hardware should
continue to compare against PCI revision ID values directly.  These are
listed in the bspec as integers, so it's easier to confirm their
correctness if we just use an integer literal rather than a symbolic
name anyway.

Since the BXT, GLK, and CNL revid macros were never used in any
workaround code, just remove them completely.

Bspec: 13620, 19131, 13626, 18329
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.c   |  8 
 drivers/gpu/drm/i915/i915_drv.h   | 24 
 drivers/gpu/drm/i915/intel_step.h |  1 +
 3 files changed, 5 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 30d8cd8c69b1..90136995f5eb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -271,10 +271,10 @@ static void intel_detect_preproduction_hw(struct 
drm_i915_private *dev_priv)
bool pre = false;
 
pre |= IS_HSW_EARLY_SDV(dev_priv);
-   pre |= IS_SKL_REVID(dev_priv, 0, SKL_REVID_F0);
-   pre |= IS_BXT_REVID(dev_priv, 0, BXT_REVID_B_LAST);
-   pre |= IS_KBL_GT_STEP(dev_priv, 0, STEP_A0);
-   pre |= IS_GLK_REVID(dev_priv, 0, GLK_REVID_A2);
+   pre |= IS_SKYLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x6;
+   pre |= IS_BROXTON(dev_priv) && INTEL_REVID(dev_priv) < 0xA;
+   pre |= IS_KABYLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x1;
+   pre |= IS_GEMINILAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x3;
 
if (pre) {
drm_err(_priv->drm, "This is a pre-production stepping. "
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6dff4ca01241..796e6838bc79 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1473,35 +1473,11 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define IS_SKL_REVID(p, since, until) (IS_SKYLAKE(p) && IS_REVID(p, since, 
until))
 
-#define BXT_REVID_A0   0x0
-#define BXT_REVID_A1   0x1
-#define BXT_REVID_B0   0x3
-#define BXT_REVID_B_LAST   0x8
-#define BXT_REVID_C0   0x9
-
-#define IS_BXT_REVID(dev_priv, since, until) \
-   (IS_BROXTON(dev_priv) && IS_REVID(dev_priv, since, until))
-
 #define IS_KBL_GT_STEP(dev_priv, since, until) \
(IS_KABYLAKE(dev_priv) && IS_GT_STEP(dev_priv, since, until))
 #define IS_KBL_DISPLAY_STEP(dev_priv, since, until) \
(IS_KABYLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, since, until))
 
-#define GLK_REVID_A0   0x0
-#define GLK_REVID_A1   0x1
-#define GLK_REVID_A2   0x2
-#define GLK_REVID_B0   0x3
-
-#define IS_GLK_REVID(dev_priv, since, until) \
-   (IS_GEMINILAKE(dev_priv) && IS_REVID(dev_priv, since, until))
-
-#define CNL_REVID_A0   0x0
-#define CNL_REVID_B0   0x1
-#define CNL_REVID_C0   0x2
-
-#define IS_CNL_REVID(p, since, until) \
-   (IS_CANNONLAKE(p) && IS_REVID(p, since, until))
-
 #define ICL_REVID_A0   0x0
 #define ICL_REVID_A2   0x1
 #define ICL_REVID_B0   0x3
diff --git a/drivers/gpu/drm/i915/intel_step.h 
b/drivers/gpu/drm/i915/intel_step.h
index 958a8bb5d677..8efacef6ab31 100644
--- a/drivers/gpu/drm/i915/intel_step.h
+++ b/drivers/gpu/drm/i915/intel_step.h
@@ -22,6 +22,7 @@ struct intel_step_info {
 enum intel_step {
STEP_NONE = 0,
STEP_A0,
+   STEP_A1,
STEP_A2,
STEP_B0,
STEP_B1,
-- 
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: do not abbreviate version in debugfs

== Series Details ==

Series: series starting with [1/2] drm/i915: do not abbreviate version in 
debugfs
URL   : https://patchwork.freedesktop.org/series/92296/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10310 -> Patchwork_20550


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u:   [PASS][1] -> [INCOMPLETE][2] ([i915#155])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10310/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20550/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html

  
 Possible fixes 

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][3] ([i915#1372]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10310/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20550/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155


Participating hosts (42 -> 40)
--

  Missing(2): fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10310 -> Patchwork_20550

  CI-20190529: 20190529
  CI_DRM_10310: 29b325c7733c8cc4fc3206d9e16792ec6b43a721 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6130: 390edfb703c346f06b0850db71bd3cc1342a3c02 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20550: 392edad5e6512e6712c14ac37d17871b09ed7f56 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

392edad5e651 drm/i915: Add release id version
b99d3141fb47 drm/i915: do not abbreviate version in debugfs

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20550/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for GPD Win Max display fixes (rev3)

== Series Details ==

Series: GPD Win Max display fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/90483/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309_full -> Patchwork_20547_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs:
- {shard-rkl}:[FAIL][1] ([i915#3678]) -> [SKIP][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-rkl-1/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-rkl-6/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html

  * igt@kms_flip_tiling@flip-changes-tiling-y:
- {shard-rkl}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-rkl-5/igt@kms_flip_til...@flip-changes-tiling-y.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-iclb8/igt@gem_...@unwedge-stress.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-iclb4/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  NOTRUN -> [FAIL][10] ([i915#2842] / [i915#3468])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html

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

  * igt@gem_exec_params@no-blt:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109283])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-iclb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_reloc@basic-wide-active@bcs0:
- shard-apl:  NOTRUN -> [FAIL][16] ([i915#3633]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-apl7/igt@gem_exec_reloc@basic-wide-act...@bcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][17] ([i915#3633])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_exec_suspend@basic-s3:
- shard-apl:  NOTRUN -> [DMESG-WARN][18] ([i915#180])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-apl1/igt@gem_exec_susp...@basic-s3.html

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

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-iclb: [PASS][20] -> [FAIL][21] ([i915#307])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-iclb7/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-xy.html

  *

[Intel-gfx] ✗ Fi.CI.BUILD: failure for CT changes required for GuC submission (rev4)

== Series Details ==

Series: CT changes required for GuC submission (rev4)
URL   : https://patchwork.freedesktop.org/series/91943/
State : failure

== Summary ==

Applying: drm/i915/guc: Relax CTB response timeout
Applying: REVIEW: Full tree diff against internal/internal
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/gem/i915_gem_context.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 REVIEW: Full tree diff against internal/internal
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: do not abbreviate version in debugfs

== Series Details ==

Series: series starting with [1/2] drm/i915: do not abbreviate version in 
debugfs
URL   : https://patchwork.freedesktop.org/series/92296/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b99d3141fb47 drm/i915: do not abbreviate version in debugfs
392edad5e651 drm/i915: Add release id version
-:48: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#48: FILE: drivers/gpu/drm/i915/i915_drv.h:1249:
+#define GRAPHICS_VER_FULL(i915)
IP_VER(INTEL_INFO(i915)->graphics_ver, \
+  INTEL_INFO(i915)->graphics_rel)

-:54: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#54: FILE: drivers/gpu/drm/i915/i915_drv.h:1255:
+#define MEDIA_VER_FULL(i915)   IP_VER(INTEL_INFO(i915)->media_ver, \
+  INTEL_INFO(i915)->media_rel)

-:70: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#70: FILE: drivers/gpu/drm/i915/intel_device_info.c:100:
+   drm_printf(p, "graphics version: %u.%02u\n", 
info->graphics_ver, info->graphics_rel);

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


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle cdclk crawling flag in standard manner

== Series Details ==

Series: drm/i915: Handle cdclk crawling flag in standard manner
URL   : https://patchwork.freedesktop.org/series/92294/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10310 -> Patchwork_20549


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u:   [PASS][1] -> [INCOMPLETE][2] ([i915#155])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10310/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20549/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html

  
 Possible fixes 

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][3] ([i915#1372]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10310/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20549/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

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

  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888


Participating hosts (42 -> 40)
--

  Missing(2): fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10310 -> Patchwork_20549

  CI-20190529: 20190529
  CI_DRM_10310: 29b325c7733c8cc4fc3206d9e16792ec6b43a721 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6130: 390edfb703c346f06b0850db71bd3cc1342a3c02 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20549: e0f0a1a12548b5c04ecb77a6e701fc4d4943cd84 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

e0f0a1a12548 drm/i915: Handle cdclk crawling flag in standard manner

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20549/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] REVIEW: Full tree diff against internal/internal

Auto-generated diff between internal/internal..internal
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 190 +-
 drivers/gpu/drm/i915/gem/i915_gem_context_types.h |   6 -
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c|  73 ++---
 drivers/gpu/drm/i915/gt/intel_context.c   |   2 +
 drivers/gpu/drm/i915/gt/intel_context.h   |  11 ++
 drivers/gpu/drm/i915/gt/intel_context_types.h |   6 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/i915_request.c   |   7 +-
 include/uapi/drm/i915_drm_prelim.h| 115 +
 9 files changed, 377 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 82b7af55ba05..583113c58e9c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -389,7 +389,6 @@ void i915_gem_context_release(struct kref *ref)
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
mutex_destroy(>mutex);
-   mutex_destroy(>parallel_submit);
 
kfree_rcu(ctx, rcu);
 }
@@ -769,8 +768,6 @@ static struct i915_gem_context *__create_context(struct 
intel_gt *gt)
mutex_init(>mutex);
INIT_LIST_HEAD(>link);
 
-   mutex_init(>parallel_submit);
-
spin_lock_init(>stale.lock);
INIT_LIST_HEAD(>stale.engines);
 
@@ -2093,6 +2090,48 @@ static bool validate_parallel_engines_layout(const 
struct set_engines *set)
return true;
 }
 
+/*
+ * Engine must be same class and form a logically contiguous mask.
+ *
+ * FIXME: Logical mask check not 100% correct but good enough for the PoC
+ */
+static bool __validate_parallel_engines_layout(struct drm_i915_private *i915,
+  struct intel_context *parent)
+{
+   u8 engine_class = parent->engine->class;
+   u8 num_siblings = hweight_long(parent->engine->logical_mask);
+   struct intel_context *child;
+   intel_engine_mask_t logical_mask = parent->engine->logical_mask;
+
+   for_each_child(parent, child) {
+   if (child->engine->class != engine_class) {
+   drm_dbg(>drm, "Class mismatch: %u, %u",
+   engine_class, child->engine->class);
+   return false;
+   }
+   if (hweight_long(child->engine->logical_mask) != num_siblings) {
+   drm_dbg(>drm, "Sibling mismatch: %u, %lu",
+   num_siblings,
+   hweight_long(child->engine->logical_mask));
+   return false;
+   }
+   if (logical_mask & child->engine->logical_mask) {
+   drm_dbg(>drm, "Overlapping logical mask: 0x%04x, 
0x%04x",
+   logical_mask, child->engine->logical_mask);
+   return false;
+   }
+   logical_mask |= child->engine->logical_mask;
+   }
+
+   if (!is_power_of_2((logical_mask >> (ffs(logical_mask) - 1)) + 1)) {
+   drm_dbg(>drm, "Non-contiguous logical mask: 0x%04x",
+   logical_mask);
+   return false;
+   }
+
+   return true;
+}
+
 static int
 set_engines__parallel_submit(struct i915_user_extension __user *base, void 
*data)
 {
@@ -2245,11 +2284,156 @@ set_engines__parallel_submit(struct 
i915_user_extension __user *base, void *data
return err;
 }
 
+static int
+set_engines__parallel2_submit(struct i915_user_extension __user *base,
+ void *data)
+{
+   struct prelim_drm_i915_context_engines_parallel2_submit __user *ext =
+   container_of_user(base, typeof(*ext), base);
+   const struct set_engines *set = data;
+   struct drm_i915_private *i915 = set->ctx->i915;
+   struct intel_context *parent, *child, *ce;
+   u64 flags;
+   int err = 0, n, i, j;
+   u16 slot, width, num_siblings;
+   struct intel_engine_cs **siblings = NULL;
+
+   if (!(intel_uc_uses_guc_submission(>gt.uc)))
+   return -ENODEV;
+
+   if (get_user(slot, >engine_index))
+   return -EFAULT;
+
+   if (get_user(width, >width))
+   return -EFAULT;
+
+   if (get_user(num_siblings, >num_siblings))
+   return -EFAULT;
+
+   if (slot >= set->engines->num_engines) {
+   drm_dbg(>drm, "Invalid placement value, %d >= %d\n",
+   slot, set->engines->num_engines);
+   return -EINVAL;
+   }
+
+   parent = set->engines->engines[slot];
+   if (parent) {
+   drm_dbg(>drm, "Context index[%d] not NULL\n", slot);
+   return -EINVAL;
+   }
+
+   if (get_user(flags, >flags))
+   return -EFAULT;
+
+   if (flags) {
+   drm_dbg(>drm, "Unknown flags

[Intel-gfx] [PATCH 0/2] Introduce set_parallel2 extension

Based on upstream feedback [1] the current set_parallel extension isn't
suitable. Add a single patch to DII implementing the new interface
agreed two upstream [2]. Intended to enable the UMDs with the upstream
interface while maintaining the old interface on DII. 

Quick IGT to prove this is working should be list shortly.

v2: Move single patch in GuC section on pile, align with agreed to
upstream interface, only include prelim* definitions. 
v3: Enable set_parallel2 via SET_PARAM IOCTL, resend for CI
v4: Fix regression when patch was merge - only do parallel checks on
user engine sets 

Signed-off-by: Matthew Brost 

[1] https://patchwork.freedesktop.org/patch/432205/?series=89840=1
[2] https://patchwork.freedesktop.org/patch/438911/?series=91417=1

Signed-off-by: Matthew Brost 


---
baseline: b7227afd06bac1fe6719136e2ddd2bfed1d85feb
pile-commit: b7a2c9136977a385659a71df837cbe5a1f775b32
range-diff:
   -:   >  930:  ad12b87b91af INTEL_DII/NOT_UPSTREAM: drm/i915: 
Introduce set_parallel2 extension
1083:  73e59e150cde ! 1084:  79b296835b1c INTEL_DII/FIXME: drm/i915/perf: add a 
parameter to control the size of OA buffer
1120:  edbc20ae1355 ! 1121:  30d02d618229 INTEL_DII/FIXME: drm/i915: Add 
context parameter for debug flags
1293:  997b317fc408 ! 1294:  016b5903b0a0 INTEL_DII: drm/i915/perf: Add OA 
formats for XEHPSDV
1364:  136064b76b92 ! 1365:  5f564d553dc8 INTEL_DII: drm/i915/xehpsdv: Expand 
total numbers of supported engines up to 256
1403:  67b729033e82 ! 1404:  4398a2322f2f INTEL_DII: drm/i915/xehpsdv: Impose 
ULLS context restrictions
1405:  b8dd2a22a952 ! 1406:  dd2fab232cf1 INTEL_DII: drm/i915: Add context 
methods to suspend and resume requests
1670:  b4633106fa13 ! 1671:  53b4a54ee2cc INTEL_DII: drm/i915/pxp: interface 
for marking contexts as using protected content
1671:  22369ab70556 ! 1672:  42234590cdf5 INTEL_DII: drm/i915/pxp: start the 
arb session on demand

 series |   1 +
 ...IXME-drm-i915-perf-add-a-parameter-to-con.patch |   4 +-
 ...IXME-drm-i915-Add-context-parameter-for-d.patch |  18 +-
 ...-drm-i915-perf-Add-OA-formats-for-XEHPSDV.patch |   4 +-
 ...rm-i915-xehpsdv-Expand-total-numbers-of-s.patch |   2 +-
 ...rm-i915-xehpsdv-Impose-ULLS-context-restr.patch |  12 +-
 ...rm-i915-Add-context-methods-to-suspend-an.patch |  38 +-
 ...rm-i915-pxp-interface-for-marking-context.patch |  16 +-
 ...rm-i915-pxp-start-the-arb-session-on-dema.patch |   2 +-
 ...OT_UPSTREAM-drm-i915-Introduce-set_parall.patch | 676 +
 10 files changed, 725 insertions(+), 48 deletions(-)

diff --git a/series b/series
index 8b77d52df40c..7db508ea974d 100644
--- a/series
+++ b/series
@@ -929,6 +929,7 @@
 0001-INTEL_DII-drm-i915-guc-Increase-GuC-log-size-for-CON.patch
 0001-INTEL_DII-NOT_UPSTREAM-drm-i915-Dump-error-capture-t.patch
 0001-INTEL_DII-NOT_UPSTREAM-drm-i915-guc-Dump-error-captu.patch
+0001-INTEL_DII-NOT_UPSTREAM-drm-i915-Introduce-set_parall.patch
 0001-INTEL_DII-END-GuC-submission-and-slpc-support.patch
 0001-INTEL_DII-BEGIN-SR-IOV-ENABLING.patch
 0001-INTEL_DII-drm-i915-guc-Update-GuC-to-62.0.3.patch
diff --git a/0001-INTEL_DII-FIXME-drm-i915-perf-add-a-parameter-to-con.patch 
b/0001-INTEL_DII-FIXME-drm-i915-perf-add-a-parameter-to-con.patch
index dd654f144374..b7a637b3813f 100644
--- a/0001-INTEL_DII-FIXME-drm-i915-perf-add-a-parameter-to-con.patch
+++ b/0001-INTEL_DII-FIXME-drm-i915-perf-add-a-parameter-to-con.patch
@@ -384,8 +384,8 @@ diff --git a/include/uapi/drm/i915_drm.h 
b/include/uapi/drm/i915_drm.h
 diff --git a/include/uapi/drm/i915_drm_prelim.h 
b/include/uapi/drm/i915_drm_prelim.h
 --- a/include/uapi/drm/i915_drm_prelim.h
 +++ b/include/uapi/drm/i915_drm_prelim.h
-@@ -393,6 +393,36 @@ struct prelim_i915_context_param_engines {
- #define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */
+@@ -508,6 +508,36 @@ struct prelim_i915_context_param_engines {
+ #define PRELIM_I915_CONTEXT_ENGINES_EXT_PARALLEL2_SUBMIT 
(PRELIM_I915_USER_EXT | 3) /* see prelim_i915_context_engines_parallel2_submit 
*/
  };
  
 +enum prelim_drm_i915_perf_property_id {
diff --git a/0001-INTEL_DII-FIXME-drm-i915-Add-context-parameter-for-d.patch 
b/0001-INTEL_DII-FIXME-drm-i915-Add-context-parameter-for-d.patch
index dfd5790ac2b8..71a5943b5536 100644
--- a/0001-INTEL_DII-FIXME-drm-i915-Add-context-parameter-for-d.patch
+++ b/0001-INTEL_DII-FIXME-drm-i915-Add-context-parameter-for-d.patch
@@ -44,7 +44,7 @@ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/
  }
  
  static void __free_engines(struct i915_gem_engines *e, unsigned int count)
-@@ -2252,6 +2255,76 @@ static int set_priority(struct i915_gem_context *ctx,
+@@ -2436,6 +2439,76 @@ static int set_priority(struct i915_gem_context *ctx,
return 0;
  }
  
@@ -121,7 +121,7 @@ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/
  static int ctx_setparam(struct drm_i915_file_private

Re: [Intel-gfx] [PATCH] drm/i915/display/tgl: Implement Wa_14013120569

2021-07-07 Thread Tolakanahalli Pradeep, Madhumitha

On Mon, 2021-07-05 at 13:28 +0300, Jani Nikula wrote:
> On Tue, 29 Jun 2021, "Souza, Jose"  wrote:
> > On Mon, 2021-06-28 at 16:50 -0700, Madhumitha Tolakanahalli Pradeep
> > wrote:
> > > PCH display HPD IRQ is not detected with default filter value.
> > > So, PP_CONTROL is manually reprogrammed.
> > > 
> > > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > > madhumitha.tolakanahalli.prad...@intel.com>
> > > ---
> > >  .../gpu/drm/i915/display/intel_display_power.c   |  8 
> > >  drivers/gpu/drm/i915/display/intel_hotplug.c | 16
> > > 
> > >  2 files changed, 24 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index 285380079aab..e44323cc76f5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -6385,8 +6385,16 @@ static void
> > > intel_power_domains_verify_state(struct drm_i915_private *i915)
> > >  
> > >  void intel_display_power_suspend_late(struct drm_i915_private
> > > *i915)
> > >  {
> > > +struct drm_i915_private *dev_priv = i915;
> > > +u32 val;
> > >   if (DISPLAY_VER(i915) >= 11 || IS_GEMINILAKE(i915) ||
> > >   IS_BROXTON(i915)) {
> > > + val = intel_de_read(dev_priv, PP_CONTROL(0));
> > > + /* Wa_14013120569:tgl */
> > > + if (IS_TIGERLAKE(i915)) {
> > > + val &= ~PANEL_POWER_ON;
> > > + intel_de_write(dev_priv, PP_CONTROL(0), val);
> > > + }
> > 
> > Code style is all wrong, please fix it and run "dim checkpatch" to
> > validate it before sending patches.
> > Also PP_CONTROL(0) don't point to the same register that the
> > workaround is talking about, between generations register address
> > change that might be
> > the case for this one.
> 
> In general, I've put a bunch of effort into moving most PPS stuff and
> PP_CONTROL reg access into intel_pps.c, not least because you must
> hold
> appropriate locks and power domain references to poke at this. You
> can't
> just mess with it nilly willy. I don't want these abstractions
> bypassed.
> 
> BR,
> Jani.

Thank you for pointing that out, I will fix this in the next version.

- Madhumitha
> 
> > This satisfy the "before going into sleep to allow CS entry" but it
> > do not restore the workaround after waking up from suspend.
> > Also you could improve the code, you are reading the register even
> > for platforms that don't need the wa, also check intel_de_rmw() it
> > is better suited
> > to this case.
> > 
> > >   bxt_enable_dc9(i915);
> > >   /* Tweaked Wa_14010685332:icp,jsp,mcc */
> > >   if (INTEL_PCH_TYPE(i915) >= PCH_ICP &&
> > > INTEL_PCH_TYPE(i915) <= PCH_MCC)
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > > b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > > index 47c85ac97c87..8e3f84100daf 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > > @@ -26,6 +26,7 @@
> > >  #include "i915_drv.h"
> > >  #include "intel_display_types.h"
> > >  #include "intel_hotplug.h"
> > > +#include "intel_de.h"
> > >  
> > >  /**
> > >   * DOC: Hotplug
> > > @@ -266,7 +267,9 @@ intel_encoder_hotplug(struct intel_encoder
> > > *encoder,
> > > struct intel_connector *connector)
> > >  {
> > >   struct drm_device *dev = connector->base.dev;
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > >   enum drm_connector_status old_status;
> > > + u32 val;
> > >   u64 old_epoch_counter;
> > >   bool ret = false;
> > >  
> > > @@ -288,6 +291,19 @@ intel_encoder_hotplug(struct intel_encoder
> > > *encoder,
> > > drm_get_connector_status_name(connector-
> > > >base.status),
> > > old_epoch_counter,
> > > connector->base.epoch_counter);
> > > +
> > > + /* Wa_14013120569:tgl */
> > > + if (IS_TIGERLAKE(dev_priv)) {
> > > + val = intel_de_read(dev_priv, PP_CONTROL(0));
> > > + if (connector->base.status ==
> > > connector_status_connected) {
> > > + val |= PANEL_POWER_ON;
> > > + intel_de_write(dev_priv, PP_CONTROL(0),
> > > val);
> > > + }
> > > + else if (connector->base.status ==
> > > connector_status_disconnected) {
> > > + val &= ~PANEL_POWER_ON;
> > > + intel_de_write(dev_priv, PP_CONTROL(0),
> > > val);
> > > + }
> > > + }
> > 
> > Not sure if this is the best place but anyways it is missing handle
> > the case were tigerlake boots with the external display connected.
> > No hotplug will happen and workaround will never be enabled.
> > 
> > >   return INTEL_HOTPLUG_CHANGED;
> > >   }
> > >   return INTEL_HOTPLUG_UNCHANGED;
> > 
> >

Re: [Intel-gfx] [PATCH] drm/i915/display/tgl: Implement Wa_14013120569

2021-07-07 Thread Tolakanahalli Pradeep, Madhumitha

On Tue, 2021-06-29 at 22:25 +, Souza, Jose wrote:
> On Mon, 2021-06-28 at 16:50 -0700, Madhumitha Tolakanahalli Pradeep
> wrote:
> > PCH display HPD IRQ is not detected with default filter value.
> > So, PP_CONTROL is manually reprogrammed.
> > 
> > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > madhumitha.tolakanahalli.prad...@intel.com>
> > ---
> >  .../gpu/drm/i915/display/intel_display_power.c   |  8 
> >  drivers/gpu/drm/i915/display/intel_hotplug.c | 16
> > 
> >  2 files changed, 24 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 285380079aab..e44323cc76f5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -6385,8 +6385,16 @@ static void
> > intel_power_domains_verify_state(struct drm_i915_private *i915)
> > 
> >  void intel_display_power_suspend_late(struct drm_i915_private
> > *i915)
> >  {
> > +struct drm_i915_private *dev_priv = i915;
> > +u32 val;
> >  if (DISPLAY_VER(i915) >= 11 || IS_GEMINILAKE(i915) ||
> >  IS_BROXTON(i915)) {
> > +val = intel_de_read(dev_priv, PP_CONTROL(0));
> > +/* Wa_14013120569:tgl */
> > +if (IS_TIGERLAKE(i915)) {
> > +val &= ~PANEL_POWER_ON;
> > +intel_de_write(dev_priv, PP_CONTROL(0), val);
> > +}
> 
> Code style is all wrong, please fix it and run "dim checkpatch" to
> validate it before sending patches.

Thanks for pointing that out, I will fix it in the next version.

> Also PP_CONTROL(0) don't point to the same register that the
> workaround is talking about, between generations register address
> change that might be
> the case for this one.

Could you point me to the right register that I need to be
programming for this WA?

> This satisfy the "before going into sleep to allow CS entry" but it
> do not restore the workaround after waking up from suspend.
> do not restore the workaround after waking up from suspend.

Ah, I missed that point, will fix it in v2.

> Also you could improve the code, you are reading the register even
> for platforms that don't need the wa, also check intel_de_rmw() it is
> better suited
> to this case.

You're right, I will move that code under IS_TIGERLAKE().
> 
> >  bxt_enable_dc9(i915);
> >  /* Tweaked Wa_14010685332:icp,jsp,mcc */
> >  if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
> > PCH_MCC)
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > index 47c85ac97c87..8e3f84100daf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> > @@ -26,6 +26,7 @@
> >  #include "i915_drv.h"
> >  #include "intel_display_types.h"
> >  #include "intel_hotplug.h"
> > +#include "intel_de.h"
> > 
> >  /**
> >   * DOC: Hotplug
> > @@ -266,7 +267,9 @@ intel_encoder_hotplug(struct intel_encoder
> > *encoder,
> >struct intel_connector *connector)
> >  {
> >  struct drm_device *dev = connector->base.dev;
> > +struct drm_i915_private *dev_priv = to_i915(dev);
> >  enum drm_connector_status old_status;
> > +u32 val;
> >  u64 old_epoch_counter;
> >  bool ret = false;
> > 
> > @@ -288,6 +291,19 @@ intel_encoder_hotplug(struct intel_encoder
> > *encoder,
> >drm_get_connector_status_name(connector->base.status),
> >old_epoch_counter,
> >connector->base.epoch_counter);
> > +
> > +/* Wa_14013120569:tgl */
> > +if (IS_TIGERLAKE(dev_priv)) {
> > +val = intel_de_read(dev_priv, PP_CONTROL(0));
> > +if (connector->base.status == connector_status_connected) {
> > +val |= PANEL_POWER_ON;
> > +intel_de_write(dev_priv, PP_CONTROL(0), val);
> > +}
> > +else if (connector->base.status == connector_status_disconnected)
> > {
> > +val &= ~PANEL_POWER_ON;
> > +intel_de_write(dev_priv, PP_CONTROL(0), val);
> > +}
> > +}
> 
> Not sure if this is the best place but anyways it is missing handle
> the case were tigerlake boots with the external display connected.
> No hotplug will happen and workaround will never be enabled.

Could you suggest a better place to add this WA?

I will add the check for TGL booting with external display connected
in v2.

> 
> >  return INTEL_HOTPLUG_CHANGED;
> >  }
> >  return INTEL_HOTPLUG_UNCHANGED;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: do not abbreviate version in debugfs

Brevity is not needed here, so just spell out "* version" in the string.

Suggested-by: Chris Wilson 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_device_info.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 7eaa92fee421..3daf0cd8d48b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -96,9 +96,9 @@ static const char *iommu_name(void)
 void intel_device_info_print_static(const struct intel_device_info *info,
struct drm_printer *p)
 {
-   drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);
-   drm_printf(p, "media_ver: %u\n", info->media_ver);
-   drm_printf(p, "display_ver: %u\n", info->display.ver);
+   drm_printf(p, "graphics version: %u\n", info->graphics_ver);
+   drm_printf(p, "media version: %u\n", info->media_ver);
+   drm_printf(p, "display version: %u\n", info->display.ver);
drm_printf(p, "gt: %d\n", info->gt);
drm_printf(p, "iommu: %s\n", iommu_name());
drm_printf(p, "memory-regions: %x\n", info->memory_regions);
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Add release id version

Besides the arch version returned by GRAPHICS_VER(), new platforms
contain a "release id" to make clear the difference from one platform to
another.

The release id number is not formally defined by hardware until future
platforms that will expose it via a new GMD_ID register.  For the
platforms we support before that register becomes available we will set
the values in software and we can set them as we please. So the plan is
to set them so we can group different features under a single
GRAPHICS_VER_FULL() check.

After GMD_ID is used, the usefulness of a "full version check" will be
greatly reduced and will be mostly used for deciding workarounds and a
few code paths. So it makes sense to keep it as a separate field from
graphics_ver. Also, as a platform with `release == n` may be closer
feature-wise to `n - 2` than to `n - 1`, use the word "release" rather
than the more common "minor" for this

This is a mix of 2 independent changes: one by me and the other by Matt
Roper.

v2:
  - Reword commit message to make it clearer why we don't call it
"minor" (Matt Roper and Tvrtko)
  - Rename variables s/*_ver_release/*_rel/ and print them in a single
line formatted as {ver}.{rel:2} (Jani and Matt Roper)

Cc: Matt Roper 
Signed-off-by: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |  6 ++
 drivers/gpu/drm/i915/intel_device_info.c | 12 ++--
 drivers/gpu/drm/i915/intel_device_info.h |  2 ++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bc6799f75670..73126b6854fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1243,11 +1243,17 @@ static inline struct drm_i915_private 
*pdev_to_i915(struct pci_dev *pdev)
 
 #define INTEL_DEVID(dev_priv)  (RUNTIME_INFO(dev_priv)->device_id)
 
+#define IP_VER(ver, rel)   ((ver) << 8 | (rel))
+
 #define GRAPHICS_VER(i915) (INTEL_INFO(i915)->graphics_ver)
+#define GRAPHICS_VER_FULL(i915)
IP_VER(INTEL_INFO(i915)->graphics_ver, \
+  INTEL_INFO(i915)->graphics_rel)
 #define IS_GRAPHICS_VER(i915, from, until) \
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
 
 #define MEDIA_VER(i915)(INTEL_INFO(i915)->media_ver)
+#define MEDIA_VER_FULL(i915)   IP_VER(INTEL_INFO(i915)->media_ver, \
+  INTEL_INFO(i915)->media_rel)
 #define IS_MEDIA_VER(i915, from, until) \
(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 3daf0cd8d48b..d2a514d2551d 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -96,8 +96,16 @@ static const char *iommu_name(void)
 void intel_device_info_print_static(const struct intel_device_info *info,
struct drm_printer *p)
 {
-   drm_printf(p, "graphics version: %u\n", info->graphics_ver);
-   drm_printf(p, "media version: %u\n", info->media_ver);
+   if (info->graphics_rel)
+   drm_printf(p, "graphics version: %u.%02u\n", 
info->graphics_ver, info->graphics_rel);
+   else
+   drm_printf(p, "graphics version: %u\n", info->graphics_ver);
+
+   if (info->media_rel)
+   drm_printf(p, "media version: %u.%02u\n", info->media_ver, 
info->media_rel);
+   else
+   drm_printf(p, "media version: %u\n", info->media_ver);
+
drm_printf(p, "display version: %u\n", info->display.ver);
drm_printf(p, "gt: %d\n", info->gt);
drm_printf(p, "iommu: %s\n", iommu_name());
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index b326aff65cd6..301bd8ba161a 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -162,7 +162,9 @@ enum intel_ppgtt_type {
 
 struct intel_device_info {
u8 graphics_ver;
+   u8 graphics_rel;
u8 media_ver;
+   u8 media_rel;
 
u8 gt; /* GT number, 0 if undefined */
intel_engine_mask_t platform_engine_mask; /* Engines supported by the 
HW */
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Handle cdclk crawling flag in standard manner

The 'has_cdclk_crawl' field in our device info structure is a boolean
flag and doesn't need a whole u8.  Add it as another 1-bit feature flag
and move it to the display section.  While we're at it, replace the
has_cdclk_crawl() function with a macro for consistency with our
handling of other feature flags.

Cc: Stanislav Lisovskiy 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 9 ++---
 drivers/gpu/drm/i915/i915_drv.h| 1 +
 drivers/gpu/drm/i915/i915_pci.c| 2 +-
 drivers/gpu/drm/i915/intel_device_info.h   | 3 +--
 4 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 613ffcc68eba..df2d8ce4a12f 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1548,11 +1548,6 @@ static void cnl_cdclk_pll_enable(struct drm_i915_private 
*dev_priv, int vco)
dev_priv->cdclk.hw.vco = vco;
 }
 
-static bool has_cdclk_crawl(struct drm_i915_private *i915)
-{
-   return INTEL_INFO(i915)->has_cdclk_crawl;
-}
-
 static void adlp_cdclk_pll_crawl(struct drm_i915_private *dev_priv, int vco)
 {
int ratio = DIV_ROUND_CLOSEST(vco, dev_priv->cdclk.hw.ref);
@@ -1649,7 +1644,7 @@ static void bxt_set_cdclk(struct drm_i915_private 
*dev_priv,
return;
}
 
-   if (has_cdclk_crawl(dev_priv) && dev_priv->cdclk.hw.vco > 0 && vco > 0) 
{
+   if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->cdclk.hw.vco > 0 && vco > 0) 
{
if (dev_priv->cdclk.hw.vco != vco)
adlp_cdclk_pll_crawl(dev_priv, vco);
} else if (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) {
@@ -1857,7 +1852,7 @@ static bool intel_cdclk_can_crawl(struct drm_i915_private 
*dev_priv,
 {
int a_div, b_div;
 
-   if (!has_cdclk_crawl(dev_priv))
+   if (!HAS_CDCLK_CRAWL(dev_priv))
return false;
 
/*
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6dff4ca01241..30129ca4049a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1647,6 +1647,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_DP_MST(dev_priv)   (INTEL_INFO(dev_priv)->display.has_dp_mst)
 
+#define HAS_CDCLK_CRAWL(dev_priv)   
(INTEL_INFO(dev_priv)->display.has_cdclk_crawl)
 #define HAS_DDI(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) 
(INTEL_INFO(dev_priv)->display.has_fpga_dbg)
 #define HAS_PSR(dev_priv)   (INTEL_INFO(dev_priv)->display.has_psr)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a7bfdd827bc8..b2deb039f954 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -984,8 +984,8 @@ static const struct intel_device_info adl_p_info = {
GEN12_FEATURES,
XE_LPD_FEATURES,
PLATFORM(INTEL_ALDERLAKE_P),
-   .has_cdclk_crawl = 1,
.require_force_probe = 1,
+   .display.has_cdclk_crawl = 1,
.display.has_modular_fia = 1,
.display.has_psr_hw_tracking = 0,
.platform_engine_mask =
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index b326aff65cd6..3582253ee05b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -141,6 +141,7 @@ enum intel_ppgtt_type {
 #define DEV_INFO_DISPLAY_FOR_EACH_FLAG(func) \
/* Keep in alphabetical order */ \
func(cursor_needs_physical); \
+   func(has_cdclk_crawl); \
func(has_dmc); \
func(has_ddi); \
func(has_dp_mst); \
@@ -185,8 +186,6 @@ struct intel_device_info {
 
u8 abox_mask;
 
-   u8 has_cdclk_crawl;  /* does support CDCLK crawling */
-
 #define DEFINE_FLAG(name) u8 name:1
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG);
 #undef DEFINE_FLAG
-- 
2.25.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 06/7] drm/i915/guc: Optimize CTB writes and reads

CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely necessary. Also store the current space in the each channel
locally.

v2:
 (Michal)
  - Add additional sanity checks for head / tail pointers
  - Use GUC_CTB_HDR_LEN rather than magic 1
v3:
 (Michal / John H)
  - Drop redundant check of head value
v4:
 (John H)
  - Drop redundant checks of tail / head values
v5:
 (Michal)
  - Address more nits

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 92 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 ++
 2 files changed, 66 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index db3e85b89573..d552d3016779 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct 
guc_ct_buffer_desc *desc)
 static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
 {
ctb->broken = false;
+   ctb->tail = 0;
+   ctb->head = 0;
+   ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
+
guc_ct_buffer_desc_init(ctb->desc);
 }
 
@@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
 {
struct intel_guc_ct_buffer *ctb = >ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
-   u32 head = desc->head;
-   u32 tail = desc->tail;
+   u32 tail = ctb->tail;
u32 size = ctb->size;
-   u32 used;
u32 header;
u32 hxg;
u32 type;
@@ -396,25 +398,22 @@ static int ct_write(struct intel_guc_ct *ct,
if (unlikely(desc->status))
goto corrupted;
 
-   if (unlikely((tail | head) >= size)) {
-   CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
-head, tail, size);
+   GEM_BUG_ON(tail > size);
+
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
+   if (unlikely(tail != READ_ONCE(desc->tail))) {
+   CT_ERROR(ct, "Tail was modified %u != %u\n",
+desc->tail, tail);
+   desc->status |= GUC_CTB_STATUS_MISMATCH;
+   goto corrupted;
+   }
+   if (unlikely(desc->head >= size)) {
+   CT_ERROR(ct, "Invalid head offset %u >= %u)\n",
+desc->head, size);
desc->status |= GUC_CTB_STATUS_OVERFLOW;
goto corrupted;
}
-
-   /*
-* tail == head condition indicates empty. GuC FW does not support
-* using up the entire buffer to get tail == head meaning full.
-*/
-   if (tail < head)
-   used = (size - head) + tail;
-   else
-   used = tail - head;
-
-   /* make sure there is a space including extra dw for the header */
-   if (unlikely(used + len + GUC_CTB_HDR_LEN >= size))
-   return -ENOSPC;
+#endif
 
/*
 * dw0: CT header (including fence)
@@ -452,6 +451,10 @@ static int ct_write(struct intel_guc_ct *ct,
 */
write_barrier(ct);
 
+   /* update local copies */
+   ctb->tail = tail;
+   ctb->space -= len + GUC_CTB_HDR_LEN;
+
/* now update descriptor */
WRITE_ONCE(desc->tail, tail);
 
@@ -469,7 +472,7 @@ static int ct_write(struct intel_guc_ct *ct,
  * @req:   pointer to pending request
  * @status:placeholder for status
  *
- * For each sent request, Guc shall send bac CT response message.
+ * For each sent request, GuC shall send back CT response message.
  * Our message handler will update status of tracked request once
  * response message with given fence is received. Wait here and
  * check for valid response status value.
@@ -525,24 +528,36 @@ static inline bool ct_deadlocked(struct intel_guc_ct *ct)
return ret;
 }
 
-static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
+static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
 {
+   struct intel_guc_ct_buffer *ctb = >ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
-   u32 head = READ_ONCE(desc->head);
+   u32 head;
u32 space;
 
-   space = CIRC_SPACE(desc->tail, head, ctb->size);
+   if (ctb->space >= len_dw)
+   return true;
+
+   head = READ_ONCE(desc->head);
+   if (unlikely(head > ctb->size)) {
+   CT_ERROR(ct, "Invalid head offset %u >= %u)\n",
+head, ctb->size);
+   desc->status |= GUC_CTB_STATUS_OVERFLOW;
+   ctb->broken = true;
+   return false;
+   }
+
+   space = CIRC_SPACE(ctb->tail, head, ctb->size);
+   ctb->space = space;
 
return space >=

[Intel-gfx] ✓ Fi.CI.BAT: success for GPD Win Max display fixes (rev3)

== Series Details ==

Series: GPD Win Max display fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/90483/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309 -> Patchwork_20547


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-tgl-1115g4}:[FAIL][1] ([i915#1888]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][3] ([i915#1372]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
 Warnings 

  * igt@runner@aborted:
- fi-kbl-x1275:   [FAIL][5] ([i915#2722] / [i915#3363]) -> [FAIL][6] 
([i915#2426] / [i915#3363])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-kbl-x1275/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/fi-kbl-x1275/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).

  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-tgl-y 


Build changes
-

  * Linux: CI_DRM_10309 -> Patchwork_20547

  CI-20190529: 20190529
  CI_DRM_10309: 6a5db0d08c45a29cebcfd39b53a15be664b9369c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6130: 390edfb703c346f06b0850db71bd3cc1342a3c02 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20547: 148b4e2e6672af19260618b464e65829e6acad92 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

148b4e2e6672 drm: Add orientation quirk for GPD Win Max
521e4b71e1c8 drm/i915/opregion: add support for mailbox #5 EDID

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20547/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Begin enabling Xe_HP SDV and DG2 platforms (rev4)

== Series Details ==

Series: Begin enabling Xe_HP SDV and DG2 platforms (rev4)
URL   : https://patchwork.freedesktop.org/series/92135/
State : failure

== Summary ==

Applying: drm/i915: Add "release id" version
Applying: drm/i915: Add XE_HP initial definitions
Applying: drm/i915: Fork DG1 interrupt handler
Applying: drm/i915/xehp: VDBOX/VEBOX fusing registers are enable-based
Applying: drm/i915/gen12: Use fuse info to enable SFC
Applying: drm/i915/selftests: Allow for larger engine counts
Applying: drm/i915/xehp: Extra media engines - Part 1 (engine definitions)
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/gt/intel_engine_cs.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0007 drm/i915/xehp: Extra media engines - Part 1 (engine 
definitions)
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Nuke GEN macros

== Series Details ==

Series: drm/i915: Nuke GEN macros
URL   : https://patchwork.freedesktop.org/series/92285/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309_full -> Patchwork_20546_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs:
- {shard-rkl}:[FAIL][1] ([i915#3678]) -> [SKIP][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-rkl-1/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-rkl-6/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html

  * igt@kms_flip_tiling@flip-changes-tiling-y:
- {shard-rkl}:NOTRUN -> [SKIP][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-rkl-1/igt@kms_flip_til...@flip-changes-tiling-y.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2410])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#2481] 
/ [i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-iclb8/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-iclb3/igt@gem_...@unwedge-stress.html

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

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

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][12] -> [SKIP][13] ([fdo#109271])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fence@basic-wait@bcs0:
- shard-kbl:  NOTRUN -> [SKIP][14] ([fdo#109271]) +63 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-kbl1/igt@gem_exec_fence@basic-w...@bcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-snb:  NOTRUN -> [SKIP][15] ([fdo#109271]) +282 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_params@no-blt:
- shard-iclb: NOTRUN -> [SKIP][16] ([fdo#109283])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-iclb5/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_reloc@basic-wide-active@bcs0:
- shard-apl:  NOTRUN -> [FAIL][17] ([i915#3633]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-apl1/igt@gem_exec_reloc@basic-wide-act...@bcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][18] ([i915#3633]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-snb6/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][19] ([i915#3633])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_exec_whisper@basic-contexts-priority:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118] / 
[i915#95])
   [20]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GPD Win Max display fixes (rev3)

== Series Details ==

Series: GPD Win Max display fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/90483/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GPD Win Max display fixes (rev3)

== Series Details ==

Series: GPD Win Max display fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/90483/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
521e4b71e1c8 drm/i915/opregion: add support for mailbox #5 EDID
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#20: 
https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/

total: 0 errors, 1 warnings, 0 checks, 141 lines checked
148b4e2e6672 drm: Add orientation quirk for GPD Win Max


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/dg2: Update modeset sequences

DG2 has some changes to the expected modesetting sequences when compared
to gen12.  Adjust our driver logic accordingly.  Although the DP
sequence is pretty similar to TGL's, there are some steps that change,
so let's split the handling for that out into a separate function.

v2:
 - Switch wait_for_us() -> _wait_for() so that we can parameterize the
   timeout rather than duplicating the macro call.  (Jani)

Bspec: 54128
Cc: Lucas De Marchi 
Cc: Anusha Srivatsa 
Cc: Jani Nikula 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 131 +--
 1 file changed, 123 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ade03cf41caa..f96dd8dde61e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -172,14 +172,18 @@ void intel_wait_ddi_buf_idle(struct drm_i915_private 
*dev_priv,
 static void intel_wait_ddi_buf_active(struct drm_i915_private *dev_priv,
  enum port port)
 {
+   int ret;
+
/* Wait > 518 usecs for DDI_BUF_CTL to be non idle */
if (DISPLAY_VER(dev_priv) < 10) {
usleep_range(518, 1000);
return;
}
 
-   if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
- DDI_BUF_IS_IDLE), 500))
+   ret = _wait_for(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
+ DDI_BUF_IS_IDLE), IS_DG2(dev_priv) ? 1200 : 500, 10, 
10);
+
+   if (ret)
drm_err(_priv->drm, "Timeout waiting for DDI BUF %c to get 
active\n",
port_name(port));
 }
@@ -2207,7 +2211,7 @@ void intel_ddi_sanitize_encoder_pll_mapping(struct 
intel_encoder *encoder)
ddi_clk_needed = false;
}
 
-   if (ddi_clk_needed || !encoder->disable_clock ||
+   if (ddi_clk_needed || !encoder->is_clock_enabled ||
!encoder->is_clock_enabled(encoder))
return;
 
@@ -2488,6 +2492,116 @@ static void intel_ddi_mso_configure(const struct 
intel_crtc_state *crtc_state)
 OVERLAP_PIXELS_MASK, dss1);
 }
 
+static void dg2_ddi_pre_enable_dp(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+   bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
+   int level = intel_ddi_dp_level(intel_dp);
+
+   intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
+crtc_state->lane_count);
+
+   /*
+* 1. Enable Power Wells
+*
+* This was handled at the beginning of intel_atomic_commit_tail(),
+* before we called down into this function.
+*/
+
+   /* 2. Enable Panel Power if PPS is required */
+   intel_pps_on(intel_dp);
+
+   /*
+* 3. Enable the port PLL.
+*/
+   intel_ddi_enable_clock(encoder, crtc_state);
+
+   /* 4. Enable IO power */
+   if (!intel_phy_is_tc(dev_priv, phy) ||
+   dig_port->tc_mode != TC_PORT_TBT_ALT)
+   dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
+  
dig_port->ddi_io_power_domain);
+
+   /*
+* 5. The rest of the below are substeps under the bspec's "Enable and
+* Train Display Port" step.  Note that steps that are specific to
+* MST will be handled by intel_mst_pre_enable_dp() before/after it
+* calls into this function.  Also intel_mst_pre_enable_dp() only calls
+* us when active_mst_links==0, so any steps designated for "single
+* stream or multi-stream master transcoder" can just be performed
+* unconditionally here.
+*/
+
+   /*
+* 5.a Configure Transcoder Clock Select to direct the Port clock to the
+* Transcoder.
+*/
+   intel_ddi_enable_pipe_clock(encoder, crtc_state);
+
+   /* 5.b Not relevant to i915 for now */
+
+   /*
+* 5.c Configure TRANS_DDI_FUNC_CTL DDI Select, DDI Mode Select & MST
+* Transport Select
+*/
+   intel_ddi_config_transcoder_func(encoder, crtc_state);
+
+   /*
+* 5.d Configure & enable DP_TP_CTL with link training pattern 1
+* selected
+*
+* This will be handled by the intel_dp_start_link_train() farther
+* down this function.
+*/
+
+   /* 5.e Configure voltage swing and related IO settings */

[Intel-gfx] [PATCH v2] drm/i915/xehpsdv: add initial XeHP SDV definitions

From: Lucas De Marchi 

XeHP SDV is a Intel® dGPU without display. This is just the definition
of some basic platform macros, by large a copy of current state of
Tigerlake which does not reflect the end state of this platform.

v2:
 - Switch to intel_step infrastructure for stepping matches. (Jani)

Bspec: 44467, 48077
Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Signed-off-by: Lucas De Marchi 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Stuart Summers 
Signed-off-by: Tomas Winkler 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 
 drivers/gpu/drm/i915/i915_pci.c  | 20 
 drivers/gpu/drm/i915/intel_device_info.c |  1 +
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 drivers/gpu/drm/i915/intel_step.c| 12 +++-
 drivers/gpu/drm/i915/intel_step.h|  1 +
 6 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 326206b2eaa0..9487cec9eba1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1406,6 +1406,7 @@ 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_XEHPSDV(dev_priv) IS_PLATFORM(dev_priv, INTEL_XEHPSDV)
 #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
 #define IS_BDW_ULT(dev_priv) \
@@ -1564,6 +1565,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
(IS_ALDERLAKE_P(__i915) && \
 IS_GT_STEP(__i915, since, until))
 
+#define IS_XEHPSDV_GT_STEP(p, since, until) \
+   (IS_XEHPSDV(p) && IS_GT_STEP(__i915, since, until))
+
 #define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp)
 #define IS_GEN9_LP(dev_priv)   (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv))
 #define IS_GEN9_BC(dev_priv)   (GRAPHICS_VER(dev_priv) == 9 && 
!IS_LP(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 8db7d38b081c..7c02d150caa0 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1020,6 +1020,26 @@ static const struct intel_device_info adl_p_info = {
.ppgtt_size = 48, \
.ppgtt_type = INTEL_PPGTT_FULL
 
+#define XE_HPM_FEATURES \
+   .media_ver = 12, \
+   .media_rel = 50
+
+__maybe_unused
+static const struct intel_device_info xehpsdv_info = {
+   XE_HP_FEATURES,
+   XE_HPM_FEATURES,
+   DGFX_FEATURES,
+   PLATFORM(INTEL_XEHPSDV),
+   .display = { },
+   .pipe_mask = 0,
+   .platform_engine_mask =
+   BIT(RCS0) | BIT(BCS0) |
+   BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
+   BIT(VCS0) | BIT(VCS1) | BIT(VCS2) | BIT(VCS3) |
+   BIT(VCS4) | BIT(VCS5) | BIT(VCS6) | BIT(VCS7),
+   .require_force_probe = 1,
+};
+
 #undef PLATFORM
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index d2a514d2551d..b750f9ded9d5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -68,6 +68,7 @@ static const char * const platform_names[] = {
PLATFORM_NAME(DG1),
PLATFORM_NAME(ALDERLAKE_S),
PLATFORM_NAME(ALDERLAKE_P),
+   PLATFORM_NAME(XEHPSDV),
 };
 #undef PLATFORM_NAME
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 2874e59e8b15..f2472ddefc1e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -88,6 +88,7 @@ enum intel_platform {
INTEL_DG1,
INTEL_ALDERLAKE_S,
INTEL_ALDERLAKE_P,
+   INTEL_XEHPSDV,
INTEL_MAX_PLATFORMS
 };
 
diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index ba9479a67521..a27a41caed70 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -54,6 +54,13 @@ static const struct intel_step_info adlp_revid_step_tbl[] = {
[0xC] = { .gt_step = STEP_C0, .display_step = STEP_D0 },
 };
 
+static const struct intel_step_info xehpsdv_revid_step_tbl[] = {
+   [0x0] = { .gt_step = STEP_A0 },
+   [0x1] = { .gt_step = STEP_A1 },
+   [0x4] = { .gt_step = STEP_B0 },
+   [0x8] = { .gt_step = STEP_C0 },
+};
+
 void intel_step_init(struct drm_i915_private *i915)
 {
const struct intel_step_info *revids = NULL;
@@ -61,7 +68,10 @@ void intel_step_init(struct drm_i915_private *i915)
int revid = INTEL_REVID(i915);
struct intel_step_info step = {};
 
-   if (IS_ALDERLAKE_P(i915)) {
+   if (IS_XEHPSDV(i915)) {
+   revids = xehpsdv_revid_step_tbl;
+   size =

[Intel-gfx] [PATCH v2] drm/i915/xehp: Extra media engines - Part 1 (engine definitions)

From: John Harrison 

Xe_HP can have a lot of extra media engines. This patch adds the basic
definitions for them.

v2:
 - Re-order intel_gt_info and intel_device_info slightly to avoid
   unnecessary padding now that we've increased the size of
   intel_engine_mask_t.  (Tvrtko)

Cc: Tvrtko Ursulin 
Signed-off-by: John Harrison 
Signed-off-by: Tomas Winkler 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c |  7 ++-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c| 50 
 drivers/gpu/drm/i915/gt/intel_engine_types.h | 14 --
 drivers/gpu/drm/i915/gt/intel_gt_types.h |  5 +-
 drivers/gpu/drm/i915/i915_reg.h  |  6 +++
 drivers/gpu/drm/i915/intel_device_info.h |  3 +-
 6 files changed, 74 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 87b06572fd2e..35edc55720f4 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -279,7 +279,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE)
aux_inv = rq->engine->mask & ~BIT(BCS0);
if (aux_inv)
-   cmd += 2 * hweight8(aux_inv) + 2;
+   cmd += 2 * hweight32(aux_inv) + 2;
 
cs = intel_ring_begin(rq, cmd);
if (IS_ERR(cs))
@@ -313,9 +313,8 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
struct intel_engine_cs *engine;
unsigned int tmp;
 
-   *cs++ = MI_LOAD_REGISTER_IMM(hweight8(aux_inv));
-   for_each_engine_masked(engine, rq->engine->gt,
-  aux_inv, tmp) {
+   *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
+   for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
*cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
*cs++ = AUX_INV;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4c37f8a7b262..79f603ce6e7e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -104,6 +104,38 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 11, .base = GEN11_BSD4_RING_BASE }
},
},
+   [VCS4] = {
+   .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+   .class = VIDEO_DECODE_CLASS,
+   .instance = 4,
+   .mmio_bases = {
+   { .graphics_ver = 11, .base = XEHP_BSD5_RING_BASE }
+   },
+   },
+   [VCS5] = {
+   .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+   .class = VIDEO_DECODE_CLASS,
+   .instance = 5,
+   .mmio_bases = {
+   { .graphics_ver = 12, .base = XEHP_BSD6_RING_BASE }
+   },
+   },
+   [VCS6] = {
+   .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+   .class = VIDEO_DECODE_CLASS,
+   .instance = 6,
+   .mmio_bases = {
+   { .graphics_ver = 12, .base = XEHP_BSD7_RING_BASE }
+   },
+   },
+   [VCS7] = {
+   .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+   .class = VIDEO_DECODE_CLASS,
+   .instance = 7,
+   .mmio_bases = {
+   { .graphics_ver = 12, .base = XEHP_BSD8_RING_BASE }
+   },
+   },
[VECS0] = {
.hw_id = VECS0_HW,
.class = VIDEO_ENHANCEMENT_CLASS,
@@ -121,6 +153,22 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 11, .base = GEN11_VEBOX2_RING_BASE }
},
},
+   [VECS2] = {
+   .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+   .class = VIDEO_ENHANCEMENT_CLASS,
+   .instance = 2,
+   .mmio_bases = {
+   { .graphics_ver = 12, .base = XEHP_VEBOX3_RING_BASE }
+   },
+   },
+   [VECS3] = {
+   .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+   .class = VIDEO_ENHANCEMENT_CLASS,
+   .instance = 3,
+   .mmio_bases = {
+   { .graphics_ver = 12, .base = XEHP_VEBOX4_RING_BASE }
+   },
+   },
 };
 
 /**
@@ -269,6 +317,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id)
 
BUILD_BUG_ON(MAX_ENGINE_CLASS >= BIT(GEN11_ENGINE_CLASS_WIDTH));
BUILD_BUG_ON(MAX_ENGINE_INSTANCE >= BIT(GEN11_ENGINE_INSTANCE_WIDTH));
+   BUILD_BUG_ON(I915_MAX_VCS > (MAX_ENGINE_INSTANCE + 1));
+   BUILD_BUG_ON(I915_MAX_VECS > (MAX_ENGINE_INSTANCE + 1));
 
if (GEM_DEBUG_WARN_ON(id >=

[Intel-gfx] [PATCH RESEND 1/2] drm/i915/opregion: add support for mailbox #5 EDID

The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.

If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.

Fixes the GPD Win Max display.

Based on original patch series by: Jani Nikula 
https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/

Changes:
 - EDID is copied and validated with drm_edid_is_valid
 - Mode is now added via drm_add_edid_modes instead of using override
   mechanism
 - squashed the two patches

Cc: Jani Nikula 
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Signed-off-by: Anisse Astier 
---
 drivers/gpu/drm/i915/display/intel_dp.c   |  3 +
 drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++-
 drivers/gpu/drm/i915/display/intel_opregion.h |  8 +++
 3 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5b52beaddada..2eaad1c9dcee 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5188,6 +5188,9 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
goto out_vdd_off;
}
 
+   /* Set up override EDID, if any, from ACPI OpRegion */
+   intel_opregion_edid_probe(intel_connector);
+
mutex_lock(>mode_config.mutex);
edid = drm_get_edid(connector, _dp->aux.ddc);
if (edid) {
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c 
b/drivers/gpu/drm/i915/display/intel_opregion.c
index dfd724e506b5..ef8d38f041eb 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -196,6 +196,8 @@ struct opregion_asle_ext {
 #define ASLE_IUER_WINDOWS_BTN  (1 << 1)
 #define ASLE_IUER_POWER_BTN(1 << 0)
 
+#define ASLE_PHED_EDID_VALID_MASK  0x3
+
 /* Software System Control Interrupt (SWSCI) */
 #define SWSCI_SCIC_INDICATOR   (1 << 0)
 #define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
@@ -909,8 +911,10 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
opregion->asle->ardy = ASLE_ARDY_NOT_READY;
}
 
-   if (mboxes & MBOX_ASLE_EXT)
+   if (mboxes & MBOX_ASLE_EXT) {
drm_dbg(_priv->drm, "ASLE extension supported\n");
+   opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
+   }
 
if (intel_load_vbt_firmware(dev_priv) == 0)
goto out;
@@ -1037,6 +1041,68 @@ intel_opregion_get_panel_type(struct drm_i915_private 
*dev_priv)
return ret - 1;
 }
 
+/**
+ * intel_opregion_edid_probe - Add EDID from ACPI OpRegion mailbox #5
+ * @intel_connector: eDP connector
+ *
+ * This reads the ACPI Opregion mailbox #5 to extract the EDID that is passed
+ * to it.
+ *
+ * Will take a lock on the DRM mode_config to add the EDID; make sure it isn't
+ * called with lock taken.
+ *
+ */
+void intel_opregion_edid_probe(struct intel_connector *intel_connector)
+{
+   struct drm_connector *connector = _connector->base;
+   struct drm_i915_private *i915 = to_i915(connector->dev);
+   struct intel_opregion *opregion = >opregion;
+   const void *in_edid;
+   const struct edid *edid;
+   struct edid *new_edid;
+   int len, ret, num;
+
+   if (!opregion->asle_ext || connector->override_edid)
+   return;
+
+   in_edid = opregion->asle_ext->bddc;
+
+   /* Validity corresponds to number of 128-byte blocks */
+   len = (opregion->asle_ext->phed & ASLE_PHED_EDID_VALID_MASK) * 128;
+   if (!len || !memchr_inv(in_edid, 0, len))
+   return;
+
+   edid = in_edid;
+
+   if (len < EDID_LENGTH * (1 + edid->extensions)) {
+   drm_dbg_kms(>drm, "Invalid EDID in ACPI OpRegion (Mailbox 
#5)\n");
+   return;
+   }
+   new_edid = drm_edid_duplicate(edid);
+   if (!new_edid) {
+   drm_err(>drm, "Cannot duplicate EDID\n");
+   return;
+   }
+   if (!drm_edid_is_valid(new_edid)) {
+   kfree(new_edid);
+   drm_dbg_kms(>drm, "Cannot validate EDID in ACPI OpRegion 
(Mailbox #5)\n");
+   return;
+   }
+
+   ret = drm_connector_update_edid_property(connector, new_edid);
+   if (ret) {
+   kfree(new_edid);
+   return;
+   }
+
+   mutex_lock(>dev->mode_config.mutex);
+   num = drm_add_edid_modes(connector, new_edid);
+   mutex_unlock(>dev->mode_config.mutex);
+
+   drm_dbg_kms(>drm, "Using OpRegion EDID for [CONNECTOR:%d:%s], 
added %d mode(s)\n",
+   connector->base.id, connector->name, num);
+}
+
 void intel_opregion_register(struct drm_i915_private *i915)
 {
struct intel_opregion *opregion = >opregion;
@@ -1127,6

[Intel-gfx] [PATCH RESEND 2/2] drm: Add orientation quirk for GPD Win Max

Panel is 800x1280, but mounted on a laptop form factor, sideways.

Reviewed-by: Hans de Goede 
Signed-off-by: Anisse Astier 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index f6bdec7fa925..3c3f4ed89173 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -148,6 +148,12 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "MicroPC"),
},
.driver_data = (void *)_rightside_up,
+   }, {/* GPD Win Max */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "GPD"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "G1619-01"),
+   },
+   .driver_data = (void *)_rightside_up,
}, {/*
 * GPD Pocket, note that the the DMI data is less generic then
 * it seems, devices with a board-vendor of "AMI Corporation"
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH RESEND v2 0/2] GPD Win Max display fixes

This patch series is for making the GPD Win Max display usable with
Linux.

The GPD Win Max is a small laptop, and its eDP panel does not send an
EDID over DPCD; the EDID is instead available in the intel opregion, in
mailbox #5 [1]

The first patch is based on Jani's patch series [2] adding support for
the opregion, with changes. I've changed authorship, but I'd be glad to
revert it

The second patch is just to fix the orientation of the panel.


Changes since v1:
 - rebased on drm-tip
 - squashed patch 1 & 2
 - picked up Reviewed-by from Hans de Goede (thanks for the review)

When v2 was initially sent [3] Ville Syrjälä suggested that it might be
a good idea to use the ACPI _DDC method instead to get the EDID, to
cover a wider range of hardware. Unfortunately, it doesn't seem
available on GPD Win Max, so I think this work should be done
independently, and this patch series considered separately.

[1]: https://gitlab.freedesktop.org/drm/intel/-/issues/3454
[2]: 
https://patchwork.kernel.org/project/intel-gfx/patch/20200828061941.17051-1-jani.nik...@intel.com/
[3]: 
https://patchwork.kernel.org/project/intel-gfx/patch/20210531204642.4907-2-ani...@astier.eu/


Anisse Astier (2):
  drm/i915/opregion: add support for mailbox #5 EDID
  drm: Add orientation quirk for GPD Win Max

 .../gpu/drm/drm_panel_orientation_quirks.c|  6 ++
 drivers/gpu/drm/i915/display/intel_dp.c   |  3 +
 drivers/gpu/drm/i915/display/intel_opregion.c | 69 ++-
 drivers/gpu/drm/i915/display/intel_opregion.h |  8 +++
 4 files changed, 85 insertions(+), 1 deletion(-)

-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: finish INTEL_GEN and friends conversion


On Wed, Jul 07, 2021 at 12:39:28PM -0700, Matt Roper wrote:

On Wed, Jul 07, 2021 at 11:13:24AM -0700, Lucas De Marchi wrote:

Commit 161058fb899e ("drm/i915: Add remaining conversions to GRAPHICS_VER")
did the last conversions to the new macros for version checks, but some
some changes sneaked in to use INTEL_GEN. Remove the last users so
we can remove the macros.

Signed-off-by: Lucas De Marchi 


Reviewed-by: Matt Roper 

I think the third change here is just one we somehow missed during the
previous conversion rather than a new use, right?


yes, looking at git log again, yes. I missed that when doing the
conversion.

thanks
Lucas De Marchi




---
 drivers/gpu/drm/i915/display/intel_display_debugfs.c | 3 ++-
 drivers/gpu/drm/i915/i915_debugfs.c  | 2 +-
 drivers/gpu/drm/i915/intel_uncore.c  | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index af9e58619667..d5af5708c9da 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -544,7 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)

seq_printf(m, "fw loaded: %s\n", 
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
-   seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >= 
12));
+   seq_printf(m, "Pipe A fw support: %s\n",
+  yesno(GRAPHICS_VER(dev_priv) >= 12));
seq_printf(m, "Pipe A fw loaded: %s\n", 
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
seq_printf(m, "Pipe B fw support: %s\n", 
yesno(IS_ALDERLAKE_P(dev_priv)));
seq_printf(m, "Pipe B fw loaded: %s\n", 
yesno(dmc->dmc_info[DMC_FW_PIPEB].payload));
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cc745751ac53..0529576f069c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -636,7 +636,7 @@ static int i915_swizzle_info(struct seq_file *m, void *data)
   intel_uncore_read16(uncore, C0DRB3_BW));
seq_printf(m, "C1DRB3 = 0x%04x\n",
   intel_uncore_read16(uncore, C1DRB3_BW));
-   } else if (INTEL_GEN(dev_priv) >= 6) {
+   } else if (GRAPHICS_VER(dev_priv) >= 6) {
seq_printf(m, "MAD_DIMM_C0 = 0x%08x\n",
   intel_uncore_read(uncore, MAD_DIMM_C0));
seq_printf(m, "MAD_DIMM_C1 = 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index d067524f9162..ee1c6fbc3d97 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1929,7 +1929,7 @@ int intel_uncore_init_mmio(struct intel_uncore *uncore)
return -ENODEV;
}

-   if (INTEL_GEN(i915) > 5 && !intel_vgpu_active(i915))
+   if (GRAPHICS_VER(i915) > 5 && !intel_vgpu_active(i915))
uncore->flags |= UNCORE_HAS_FORCEWAKE;

if (!intel_uncore_has_forcewake(uncore)) {
--
2.31.1



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

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/opregion: add support for mailbox #5 EDID

Le Wed, Jul 07, 2021 at 02:57:47PM -0500, Daniel Dadap a écrit :
> On 6/1/21 5:43 PM, Anisse Astier wrote:
> > 
> > Le Tue, Jun 01, 2021 at 06:50:24PM +0300, Ville Syrj?l? a ?crit :
> > > On Mon, May 31, 2021 at 10:46:41PM +0200, Anisse Astier wrote:
> > > > The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
> > > > used for the embedded display. Add support for using it via by adding
> > > > the EDID to the list of available modes on the connector, and use it for
> > > > eDP when available.
> > > > 
> > > > If a panel's EDID is broken, there may be an override EDID set in the
> > > > ACPI OpRegion mailbox #5. Use it if available.
> > > Looks like Windows uses the ACPI _DDC method instead. We should probably
> > > do the same, just in case some crazy machine stores the EDID somewhere
> > > else.
> > Thanks, I wouldn't have thought of this. It seems Daniel Dadap did a
> > patch series to do just that, in a generic way:
> > https://lore.kernel.org/amd-gfx/20200727205357.27839-1-dda...@nvidia.com/
> > 
> > I've tried patch 1 & 2, and after a fix[1] was able to call the _DDC method
> > on most devices, but without any EDID being returned.
> > 
> > I looked at the disassembled ACPI tables[2], and could not find any
> > device with the _DDC method. Are you sure it's the only method the
> > Windows driver uses to get the EDID ?
> 
> 
> _DDC only works on devices that actually implement it, and the vast majority
> of devices don't, because the display just provides an EDID normally. AIUI,
> usually a device will implement _DDC either because an embedded panel has no
> ROM of its own to deliver an EDID, or to allow the EDID to be read by either
> GPU on a system with a muxed display, regardless of which GPU happens to
> have the DDC lines (in TMDS) or DP AUX routed to it at the moment. (To my
> knowledge, nobody actually muxes DP AUX independently from the main link,
> but there were some older pre-DP designs where DDC could be muxed
> independently.)
> 
> I'm not sure whether the comment about Windows using _DDC was meant for this
> device in particular, or just more generally, since DDC is part of the ACPI
> spec and some Windows GPU drivers *do* use it, where available. If it was
> meant for a particular device, then it's possible that the ACPI tables
> advertise different methods depending on e.g. _OSI. If you haven't already
> tried doing so, it might be worth overriding _OSI to spoof Windows, to see
> if _DDC gets advertised.

I think it's already the default Linux behaviour according to
https://www.kernel.org/doc/html/latest/firmware-guide/acpi/osi.html

I added a few specific Windows versions (2007 - 2020), but did not see
any difference.


> 
> I'm not sure how you were able to call _DDC without an EDID being returned
> as described above, if there was no _DDC method in the ACPI tables; I would
> expect that attempting to call _DDC would fail to locate a suitable method
> and do_acpi_ddc would return NULL.

I wasn't, I just tried calling the method on all devices (removing the
_DOD id check), but obviously it failed because it did not exist.

> 
> 
> > Regards,
> > 
> > Anisse
> > 
> > [1] _DOD ids should only use 16 lower bits, see table here:
> > https://uefi.org/specs/ACPI/6.4/Apx_B_Video_Extensions/display-specific-methods.html#dod-enumerate-all-devices-attached-to-the-display-adapter
> 
> 
> Thanks; I don't see a version of your modified patch here, was the fix just
> to mask the _DOD IDs against 0x?

Yes, nothing fancy:

-   if (adr == dod_entries[i]) {
+   if (adr == (dod_entries[i] & 0x) ) {


Regards,

Anisse
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/56] drm/i915/guc: Optimize CTB writes and reads

2021-07-07 Thread Michal Wajdeczko

Hi,

On 07.07.2021 21:09, Matthew Brost wrote:
> CTB writes are now in the path of command submission and should be
> optimized for performance. Rather than reading CTB descriptor values
> (e.g. head, tail) which could result in accesses across the PCIe bus,
> store shadow local copies and only read/write the descriptor values when
> absolutely necessary. Also store the current space in the each channel
> locally.
> 
> v2:
>  (Michal)
>   - Add additional sanity checks for head / tail pointers
>   - Use GUC_CTB_HDR_LEN rather than magic 1
> v3:
>  (Michal / John H)
>   - Drop redundant check of head value
> v4:
>  (John H)
>   - Drop redundant checks of tail / head values

mostly nits, but since you will be sending it again...

> 
> Signed-off-by: John Harrison 
> Signed-off-by: Matthew Brost 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 87 ++-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 ++
>  2 files changed, 61 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index db3e85b89573..37fe9f3bbce3 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct 
> guc_ct_buffer_desc *desc)
>  static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
>  {
>   ctb->broken = false;
> + ctb->tail = 0;
> + ctb->head = 0;
> + ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
> +
>   guc_ct_buffer_desc_init(ctb->desc);
>  }
>  
> @@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
>  {
>   struct intel_guc_ct_buffer *ctb = >ctbs.send;
>   struct guc_ct_buffer_desc *desc = ctb->desc;
> - u32 head = desc->head;
> - u32 tail = desc->tail;
> + u32 tail = ctb->tail;
>   u32 size = ctb->size;
> - u32 used;
>   u32 header;
>   u32 hxg;
>   u32 type;
> @@ -396,25 +398,22 @@ static int ct_write(struct intel_guc_ct *ct,
>   if (unlikely(desc->status))
>   goto corrupted;
>  
> - if (unlikely((tail | head) >= size)) {
> - CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> -  head, tail, size);
> + GEM_BUG_ON(tail > size);
> +
> +#ifdef CONFIG_DRM_I915_DEBUG_GUC
> + if (unlikely(tail != READ_ONCE(desc->tail))) {
> + CT_ERROR(ct, "Tail was modified %u != %u\n",
> +  desc->tail, ctb->tail);

here you accessing desc->tail again so maybe we can use:

u32 raw __maybe_unused;

raw = READ_ONCE(desc->tail);
if (unlikely(raw != tail)) ...
CT_ERROR(..., raw, tail);

> + desc->status |= GUC_CTB_STATUS_MISMATCH;
> + goto corrupted;
> + }
> + if (unlikely(desc->head >= size)) {

above you are reading value from desc using READ_ONCE, could be

raw = READ_ONCE(desc->head);
if (unlikely(raw >= size)) ...
CT_ERROR(..., raw, size);

> + CT_ERROR(ct, "Invalid offsets head=%u (size=%u)\n",

"Invalid head offset %u > %u\n" ?

> +  desc->head, size);
>   desc->status |= GUC_CTB_STATUS_OVERFLOW;
>   goto corrupted;
>   }
> -
> - /*
> -  * tail == head condition indicates empty. GuC FW does not support
> -  * using up the entire buffer to get tail == head meaning full.
> -  */
> - if (tail < head)
> - used = (size - head) + tail;
> - else
> - used = tail - head;
> -
> - /* make sure there is a space including extra dw for the header */
> - if (unlikely(used + len + GUC_CTB_HDR_LEN >= size))
> - return -ENOSPC;
> +#endif
>  
>   /*
>* dw0: CT header (including fence)
> @@ -453,7 +452,9 @@ static int ct_write(struct intel_guc_ct *ct,
>   write_barrier(ct);
>  
>   /* now update descriptor */
> + ctb->tail = tail;
>   WRITE_ONCE(desc->tail, tail);
> + ctb->space -= len + GUC_CTB_HDR_LEN;

maybe keep ctb updates together?

+   /* update local copies */
+   ctb->tail = tail;
+   ctb->space -= len + GUC_CTB_HDR_LEN;
+
/* now update descriptor */
WRITE_ONCE(desc->tail, tail);

>  
>   return 0;
>  
> @@ -469,7 +470,7 @@ static int ct_write(struct intel_guc_ct *ct,
>   * @req: pointer to pending request
>   * @status:  placeholder for status
>   *
> - * For each sent request, Guc shall send bac CT response message.
> + * For each sent request, GuC shall send back CT response message.
>   * Our message handler will update status of tracked request once
>   * response message with given fence is received. Wait here and
>   * check for valid response status value.
> @@ -525,24 +526,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct 
> *ct)
>   return ret;
>  }
>  
> -static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32

Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Optimize CTB writes and reads

On Wed, Jul 07, 2021 at 01:21:35PM -0700, John Harrison wrote:
> On 7/7/2021 11:56, Matthew Brost wrote:
> 
> > Ok, I sent it but I looks like patchworks didn't like it. Anyways we
> > should be able to review that patch.
> > 
> > Matt
> Maybe because it came out as 6/56 instead of 6/7? Also, not sure if it needs
> to be in reply to 0/7 or 6/7?

Yea, that is probably it. I think 6/7 would've made patckworks happy.

Matt

> 
> John.
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Optimize CTB writes and reads

2021-07-07 Thread John Harrison


On 7/7/2021 11:56, Matthew Brost wrote:


Ok, I sent it but I looks like patchworks didn't like it. Anyways we
should be able to review that patch.

Matt
Maybe because it came out as 6/56 instead of 6/7? Also, not sure if it 
needs to be in reply to 0/7 or 6/7?


John.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/opregion: add support for mailbox #5 EDID

2021-07-07 Thread Daniel Dadap

On 6/1/21 5:43 PM, Anisse Astier wrote:

Le Tue, Jun 01, 2021 at 06:50:24PM +0300, Ville Syrj?l? a ?crit :

On Mon, May 31, 2021 at 10:46:41PM +0200, Anisse Astier wrote:

The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.

If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.

Looks like Windows uses the ACPI _DDC method instead. We should probably
do the same, just in case some crazy machine stores the EDID somewhere
else.

Thanks, I wouldn't have thought of this. It seems Daniel Dadap did a
patch series to do just that, in a generic way:
https://lore.kernel.org/amd-gfx/20200727205357.27839-1-dda...@nvidia.com/

I've tried patch 1 & 2, and after a fix[1] was able to call the _DDC method
on most devices, but without any EDID being returned.

I looked at the disassembled ACPI tables[2], and could not find any
device with the _DDC method. Are you sure it's the only method the
Windows driver uses to get the EDID ?

_DDC only works on devices that actually implement it, and the vast
majority of devices don't, because the display just provides an EDID
normally. AIUI, usually a device will implement _DDC either because an
embedded panel has no ROM of its own to deliver an EDID, or to allow the
EDID to be read by either GPU on a system with a muxed display,
regardless of which GPU happens to have the DDC lines (in TMDS) or DP
AUX routed to it at the moment. (To my knowledge, nobody actually muxes
DP AUX independently from the main link, but there were some older
pre-DP designs where DDC could be muxed independently.)

I'm not sure whether the comment about Windows using _DDC was meant for
this device in particular, or just more generally, since DDC is part of
the ACPI spec and some Windows GPU drivers *do* use it, where available.
If it was meant for a particular device, then it's possible that the
ACPI tables advertise different methods depending on e.g. _OSI. If you
haven't already tried doing so, it might be worth overriding _OSI to
spoof Windows, to see if _DDC gets advertised.

I'm not sure how you were able to call _DDC without an EDID being
returned as described above, if there was no _DDC method in the ACPI
tables; I would expect that attempting to call _DDC would fail to locate
a suitable method and do_acpi_ddc would return NULL.

Regards,

Anisse

[1] _DOD ids should only use 16 lower bits, see table here:
https://uefi.org/specs/ACPI/6.4/Apx_B_Video_Extensions/display-specific-methods.html#dod-enumerate-all-devices-attached-to-the-display-adapter

Thanks; I don't see a version of your modified patch here, was the fix
just to mask the _DOD IDs against 0x?

[2] acpidump: https://gitlab.freedesktop.org/drm/intel/-/issues/3454#note_913970

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/fbc: Rework CFB stride/size calculations (rev2)

== Series Details ==

Series: drm/i915/fbc: Rework CFB stride/size calculations (rev2)
URL   : https://patchwork.freedesktop.org/series/92163/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309_full -> Patchwork_20545_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- {shard-rkl}:[SKIP][1] ([i915#3721]) -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-rkl-2/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-rkl-6/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs:
- {shard-rkl}:[FAIL][3] ([i915#3678]) -> [SKIP][4] +4 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-rkl-1/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-rkl-6/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html

  * igt@kms_flip_tiling@flip-changes-tiling-y:
- {shard-rkl}:NOTRUN -> [SKIP][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-rkl-1/igt@kms_flip_til...@flip-changes-tiling-y.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-tglb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html

  * igt@gem_exec_fence@basic-wait@bcs0:
- shard-kbl:  NOTRUN -> [SKIP][12] ([fdo#109271]) +57 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-kbl4/igt@gem_exec_fence@basic-w...@bcs0.html

  * igt@gem_exec_params@no-blt:
- shard-iclb: NOTRUN -> [SKIP][13] ([fdo#109283])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-iclb8/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_reloc@basic-wide-active@bcs0:
- shard-apl:  NOTRUN -> [FAIL][14] ([i915#3633]) +3 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-apl1/igt@gem_exec_reloc@basic-wide-act...@bcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][15] ([i915#3633]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][16] ([i915#3633])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_exec_whisper@basic-contexts-all:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#118] / 
[i915#95])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-glk1/igt@gem_exec_whis...@basic-contexts-all.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/shard-glk3/igt@gem_exec_whis...@basic-contexts-all.html

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

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][20] ([i915#2658])
   [20]:

Re: [Intel-gfx] [PATCH 3/3] gpu/drm/i915: nuke old GEN macros

On Wed, Jul 07, 2021 at 11:13:25AM -0700, Lucas De Marchi wrote:
> Now that all the codebase is converted to the new *VER macros, remove
> the old GEN ones.
> 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matt Roper 

We're still going to need another patch or two to kill off
IS_GEN9_{BC,LP}, but we can do that separately.  We're less likely to be
adding new instances of those macros now anyway.

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 15 ---
>  1 file changed, 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6dff4ca01241..bc6799f75670 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1243,21 +1243,6 @@ static inline struct drm_i915_private 
> *pdev_to_i915(struct pci_dev *pdev)
>  
>  #define INTEL_DEVID(dev_priv)(RUNTIME_INFO(dev_priv)->device_id)
>  
> -/*
> - * Deprecated: this will be replaced by individual IP checks:
> - * GRAPHICS_VER(), MEDIA_VER() and DISPLAY_VER()
> - */
> -#define INTEL_GEN(dev_priv)  GRAPHICS_VER(dev_priv)
> -/*
> - * Deprecated: use IS_GRAPHICS_VER(), IS_MEDIA_VER() and IS_DISPLAY_VER() as
> - * appropriate.
> - */
> -#define IS_GEN_RANGE(dev_priv, s, e) IS_GRAPHICS_VER(dev_priv, (s), (e))
> -/*
> - * Deprecated: use GRAPHICS_VER(), MEDIA_VER() and DISPLAY_VER() as 
> appropriate.
> - */
> -#define IS_GEN(dev_priv, n)  (GRAPHICS_VER(dev_priv) == (n))
> -
>  #define GRAPHICS_VER(i915)   (INTEL_INFO(i915)->graphics_ver)
>  #define IS_GRAPHICS_VER(i915, from, until) \
>   (GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
> -- 
> 2.31.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: finish INTEL_GEN and friends conversion

On Wed, Jul 07, 2021 at 11:13:24AM -0700, Lucas De Marchi wrote:
> Commit 161058fb899e ("drm/i915: Add remaining conversions to GRAPHICS_VER")
> did the last conversions to the new macros for version checks, but some
> some changes sneaked in to use INTEL_GEN. Remove the last users so
> we can remove the macros.
> 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matt Roper 

I think the third change here is just one we somehow missed during the
previous conversion rather than a new use, right?

> ---
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 3 ++-
>  drivers/gpu/drm/i915/i915_debugfs.c  | 2 +-
>  drivers/gpu/drm/i915/intel_uncore.c  | 2 +-
>  3 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index af9e58619667..d5af5708c9da 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -544,7 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
>  
>   seq_printf(m, "fw loaded: %s\n", 
> yesno(intel_dmc_has_payload(dev_priv)));
>   seq_printf(m, "path: %s\n", dmc->fw_path);
> - seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >= 
> 12));
> + seq_printf(m, "Pipe A fw support: %s\n",
> +yesno(GRAPHICS_VER(dev_priv) >= 12));
>   seq_printf(m, "Pipe A fw loaded: %s\n", 
> yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
>   seq_printf(m, "Pipe B fw support: %s\n", 
> yesno(IS_ALDERLAKE_P(dev_priv)));
>   seq_printf(m, "Pipe B fw loaded: %s\n", 
> yesno(dmc->dmc_info[DMC_FW_PIPEB].payload));
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index cc745751ac53..0529576f069c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -636,7 +636,7 @@ static int i915_swizzle_info(struct seq_file *m, void 
> *data)
>  intel_uncore_read16(uncore, C0DRB3_BW));
>   seq_printf(m, "C1DRB3 = 0x%04x\n",
>  intel_uncore_read16(uncore, C1DRB3_BW));
> - } else if (INTEL_GEN(dev_priv) >= 6) {
> + } else if (GRAPHICS_VER(dev_priv) >= 6) {
>   seq_printf(m, "MAD_DIMM_C0 = 0x%08x\n",
>  intel_uncore_read(uncore, MAD_DIMM_C0));
>   seq_printf(m, "MAD_DIMM_C1 = 0x%08x\n",
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index d067524f9162..ee1c6fbc3d97 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1929,7 +1929,7 @@ int intel_uncore_init_mmio(struct intel_uncore *uncore)
>   return -ENODEV;
>   }
>  
> - if (INTEL_GEN(i915) > 5 && !intel_vgpu_active(i915))
> + if (GRAPHICS_VER(i915) > 5 && !intel_vgpu_active(i915))
>   uncore->flags |= UNCORE_HAS_FORCEWAKE;
>  
>   if (!intel_uncore_has_forcewake(uncore)) {
> -- 
> 2.31.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/display/xelpd: Fix incorrect color capability reporting

2021-07-07 Thread Sharma, Swati2


Reviewed-by: Swati Sharma 

On 07-Jul-21 3:22 PM, Uma Shankar wrote:

On XELPD platforms, color management support is not yet enabled.
Fix wrongly reporting the same through platform info, which was
resulting in incorrect initialization and usage.

Cc: Swati Sharma 
Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/i915_pci.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a7bfdd827bc8..8ff1990528d1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -947,7 +947,7 @@ static const struct intel_device_info adl_s_info = {
  
  #define XE_LPD_FEATURES \

.abox_mask = GENMASK(1, 0), 
\
-   .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 },  
\
+   .color = { .degamma_lut_size = 0, .gamma_lut_size = 0 },
\
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |  
\
BIT(TRANSCODER_C) | BIT(TRANSCODER_D),  
\
.dbuf.size = 4096,  
\



--
~Swati Sharma
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: finish INTEL_GEN and friends conversion

On Wed, Jul 07, 2021 at 11:13:23AM -0700, Lucas De Marchi wrote:
> Commit c816723b6b8a ("drm/i915/gt: replace IS_GEN and friends with
> GRAPHICS_VER") converted INTEL_GEN and friends to the new version check
> macros.  Meanwhile, some changes sneaked in to use INTEL_GEN. Remove the
> last users so we can remove the macros.
> 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/gt/intel_migrate.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index 23c59ce66cee..14afa1974ea5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -277,7 +277,7 @@ static int emit_pte(struct i915_request *rq,
>   u32 *hdr, *cs;
>   int pkt;
>  
> - GEM_BUG_ON(INTEL_GEN(rq->engine->i915) < 8);
> + GEM_BUG_ON(GRAPHICS_VER(rq->engine->i915) < 8);
>  
>   /* Compute the page directory offset for the target address range */
>   offset += (u64)rq->engine->instance << 32;
> @@ -347,11 +347,11 @@ static int emit_pte(struct i915_request *rq,
>   return total;
>  }
>  
> -static bool wa_1209644611_applies(int gen, u32 size)
> +static bool wa_1209644611_applies(int ver, u32 size)
>  {
>   u32 height = size >> PAGE_SHIFT;
>  
> - if (gen != 11)
> + if (ver != 11)
>   return false;
>  
>   return height % 4 == 3 && height <= 8;
> @@ -359,15 +359,15 @@ static bool wa_1209644611_applies(int gen, u32 size)
>  
>  static int emit_copy(struct i915_request *rq, int size)
>  {
> - const int gen = INTEL_GEN(rq->engine->i915);
> + const int ver = GRAPHICS_VER(rq->engine->i915);
>   u32 instance = rq->engine->instance;
>   u32 *cs;
>  
> - cs = intel_ring_begin(rq, gen >= 8 ? 10 : 6);
> + cs = intel_ring_begin(rq, ver >= 8 ? 10 : 6);
>   if (IS_ERR(cs))
>   return PTR_ERR(cs);
>  
> - if (gen >= 9 && !wa_1209644611_applies(gen, size)) {
> + if (ver >= 9 && !wa_1209644611_applies(ver, size)) {
>   *cs++ = GEN9_XY_FAST_COPY_BLT_CMD | (10 - 2);
>   *cs++ = BLT_DEPTH_32 | PAGE_SIZE;
>   *cs++ = 0;
> @@ -378,7 +378,7 @@ static int emit_copy(struct i915_request *rq, int size)
>   *cs++ = PAGE_SIZE;
>   *cs++ = 0; /* src offset */
>   *cs++ = instance;
> - } else if (gen >= 8) {
> + } else if (ver >= 8) {
>   *cs++ = XY_SRC_COPY_BLT_CMD | BLT_WRITE_RGBA | (10 - 2);
>   *cs++ = BLT_DEPTH_32 | BLT_ROP_SRC_COPY | PAGE_SIZE;
>   *cs++ = 0;
> @@ -491,17 +491,17 @@ intel_context_migrate_copy(struct intel_context *ce,
>  
>  static int emit_clear(struct i915_request *rq, int size, u32 value)
>  {
> - const int gen = INTEL_GEN(rq->engine->i915);
> + const int ver = GRAPHICS_VER(rq->engine->i915);
>   u32 instance = rq->engine->instance;
>   u32 *cs;
>  
>   GEM_BUG_ON(size >> PAGE_SHIFT > S16_MAX);
>  
> - cs = intel_ring_begin(rq, gen >= 8 ? 8 : 6);
> + cs = intel_ring_begin(rq, ver >= 8 ? 8 : 6);
>   if (IS_ERR(cs))
>   return PTR_ERR(cs);
>  
> - if (gen >= 8) {
> + if (ver >= 8) {
>   *cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (7 - 2);
>   *cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
>   *cs++ = 0;
> -- 
> 2.31.1
> 

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Nuke GEN macros

== Series Details ==

Series: drm/i915: Nuke GEN macros
URL   : https://patchwork.freedesktop.org/series/92285/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309 -> Patchwork_20546


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-cfl-8109u:   NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/fi-cfl-8109u/igt@kms_chamel...@hdmi-hpd-fast.html

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

  * igt@kms_psr@primary_mmap_gtt:
- fi-cfl-8109u:   NOTRUN -> [SKIP][4] ([fdo#109271]) +6 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/fi-cfl-8109u/igt@kms_psr@primary_mmap_gtt.html

  * igt@runner@aborted:
- fi-cfl-8109u:   NOTRUN -> [FAIL][5] ([i915#2722] / [i915#3363])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/fi-cfl-8109u/igt@run...@aborted.html

  * igt@vgem_basic@unload:
- fi-cfl-8109u:   NOTRUN -> [INCOMPLETE][6] ([i915#3744])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/fi-cfl-8109u/igt@vgem_ba...@unload.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u:   [INCOMPLETE][7] ([i915#155]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][9] ([i915#1372]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
 Warnings 

  * igt@runner@aborted:
- fi-bdw-5557u:   [FAIL][11] ([i915#2722]) -> [FAIL][12] ([i915#1602] / 
[i915#2029])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-bdw-5557u/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/fi-bdw-5557u/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#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1887]: https://gitlab.freedesktop.org/drm/intel/issues/1887
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3744]: https://gitlab.freedesktop.org/drm/intel/issues/3744
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10309 -> Patchwork_20546

  CI-20190529: 20190529
  CI_DRM_10309: 6a5db0d08c45a29cebcfd39b53a15be664b9369c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6130: 390edfb703c346f06b0850db71bd3cc1342a3c02 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20546: 23d96a4d67bfb00436cfd1bebccf153d6a32335e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

23d96a4d67bf gpu/drm/i915: nuke old GEN macros
f9745b901a4e drm/i915: finish INTEL_GEN and friends conversion
8abecae5e8d1 drm/i915/gt: finish INTEL_GEN and friends conversion

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20546/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Optimize CTB writes and reads

On Wed, Jul 07, 2021 at 11:19:01AM -0700, John Harrison wrote:
> On 7/7/2021 10:50, Matthew Brost wrote:
> > On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:
> > > On 7/6/2021 15:20, Matthew Brost wrote:
> > > > CTB writes are now in the path of command submission and should be
> > > > optimized for performance. Rather than reading CTB descriptor values
> > > > (e.g. head, tail) which could result in accesses across the PCIe bus,
> > > > store shadow local copies and only read/write the descriptor values when
> > > > absolutely necessary. Also store the current space in the each channel
> > > > locally.
> > > > 
> > > > v2:
> > > >(Michal)
> > > > - Add additional sanity checks for head / tail pointers
> > > > - Use GUC_CTB_HDR_LEN rather than magic 1
> > > > v3:
> > > >(Michal / John H)
> > > > - Drop redundant check of head value
> > > > 
> > > > Signed-off-by: John Harrison 
> > > > Signed-off-by: Matthew Brost 
> > > > ---
> > > >drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 88 
> > > > +++
> > > >drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 ++
> > > >2 files changed, 65 insertions(+), 29 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > > > index db3e85b89573..4a73a1f03a9b 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > > > @@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct 
> > > > guc_ct_buffer_desc *desc)
> > > >static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> > > >{
> > > > ctb->broken = false;
> > > > +   ctb->tail = 0;
> > > > +   ctb->head = 0;
> > > > +   ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
> > > > +
> > > > guc_ct_buffer_desc_init(ctb->desc);
> > > >}
> > > > @@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
> > > >{
> > > > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > > struct guc_ct_buffer_desc *desc = ctb->desc;
> > > > -   u32 head = desc->head;
> > > > -   u32 tail = desc->tail;
> > > > +   u32 tail = ctb->tail;
> > > > u32 size = ctb->size;
> > > > -   u32 used;
> > > > u32 header;
> > > > u32 hxg;
> > > > u32 type;
> > > > @@ -396,25 +398,22 @@ static int ct_write(struct intel_guc_ct *ct,
> > > > if (unlikely(desc->status))
> > > > goto corrupted;
> > > > -   if (unlikely((tail | head) >= size)) {
> > > > +   GEM_BUG_ON(tail > size);
> > > > +
> > > > +#ifdef CONFIG_DRM_I915_DEBUG_GUC
> > > > +   if (unlikely(tail != READ_ONCE(desc->tail))) {
> > > > +   CT_ERROR(ct, "Tail was modified %u != %u\n",
> > > > +desc->tail, ctb->tail);
> > > > +   desc->status |= GUC_CTB_STATUS_MISMATCH;
> > > > +   goto corrupted;
> > > > +   }
> > > > +   if (unlikely((desc->tail | desc->head) >= size)) {
> > > Same arguments below about head apply to tail here. Also, there is no 
> > > #else
> > Yes, desc->tail can be removed from this check. Same for head below. Can
> > you fix this when merging?
> > 
> > > check on ctb->head?
> > ctb->head variable isn't used in this path nor is ctb->tail in the
> > other. In the other path desc->tail is checked as it is read while
> > desc->head isn't needed to be read here. The other path can also likely
> > be reworked to pull the tail check outside of the if / else define
> > block.
> > 
> > > > CT_ERROR(ct, "Invalid offsets head=%u tail=%u 
> > > > (size=%u)\n",
> > > > -head, tail, size);
> > > > +desc->head, desc->tail, size);
> > > > desc->status |= GUC_CTB_STATUS_OVERFLOW;
> > > > goto corrupted;
> > > > }
> > > > -
> > > > -   /*
> > > > -* tail == head condition indicates empty. GuC FW does not 
> > > > support
> > > > -* using up the entire buffer to get tail == head meaning full.
> > > > -*/
> > > > -   if (tail < head)
> > > > -   used = (size - head) + tail;
> > > > -   else
> > > > -   used = tail - head;
> > > > -
> > > > -   /* make sure there is a space including extra dw for the header 
> > > > */
> > > > -   if (unlikely(used + len + GUC_CTB_HDR_LEN >= size))
> > > > -   return -ENOSPC;
> > > > +#endif
> > > > /*
> > > >  * dw0: CT header (including fence)
> > > > @@ -453,7 +452,9 @@ static int ct_write(struct intel_guc_ct *ct,
> > > > write_barrier(ct);
> > > > /* now update descriptor */
> > > > +   ctb->tail = tail;
> > > > WRITE_ONCE(desc->tail, tail);
> > > > +   ctb->space -= len + GUC_CTB_HDR_LEN;
> > > > return 0;
> > > > @@ -469,7 +470,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > > >

[Intel-gfx] [PATCH 06/56] drm/i915/guc: Optimize CTB writes and reads

CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely necessary. Also store the current space in the each channel
locally.

v2:
 (Michal)
  - Add additional sanity checks for head / tail pointers
  - Use GUC_CTB_HDR_LEN rather than magic 1
v3:
 (Michal / John H)
  - Drop redundant check of head value
v4:
 (John H)
  - Drop redundant checks of tail / head values

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 87 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 ++
 2 files changed, 61 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index db3e85b89573..37fe9f3bbce3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct 
guc_ct_buffer_desc *desc)
 static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
 {
ctb->broken = false;
+   ctb->tail = 0;
+   ctb->head = 0;
+   ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
+
guc_ct_buffer_desc_init(ctb->desc);
 }
 
@@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
 {
struct intel_guc_ct_buffer *ctb = >ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
-   u32 head = desc->head;
-   u32 tail = desc->tail;
+   u32 tail = ctb->tail;
u32 size = ctb->size;
-   u32 used;
u32 header;
u32 hxg;
u32 type;
@@ -396,25 +398,22 @@ static int ct_write(struct intel_guc_ct *ct,
if (unlikely(desc->status))
goto corrupted;
 
-   if (unlikely((tail | head) >= size)) {
-   CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
-head, tail, size);
+   GEM_BUG_ON(tail > size);
+
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
+   if (unlikely(tail != READ_ONCE(desc->tail))) {
+   CT_ERROR(ct, "Tail was modified %u != %u\n",
+desc->tail, ctb->tail);
+   desc->status |= GUC_CTB_STATUS_MISMATCH;
+   goto corrupted;
+   }
+   if (unlikely(desc->head >= size)) {
+   CT_ERROR(ct, "Invalid offsets head=%u (size=%u)\n",
+desc->head, size);
desc->status |= GUC_CTB_STATUS_OVERFLOW;
goto corrupted;
}
-
-   /*
-* tail == head condition indicates empty. GuC FW does not support
-* using up the entire buffer to get tail == head meaning full.
-*/
-   if (tail < head)
-   used = (size - head) + tail;
-   else
-   used = tail - head;
-
-   /* make sure there is a space including extra dw for the header */
-   if (unlikely(used + len + GUC_CTB_HDR_LEN >= size))
-   return -ENOSPC;
+#endif
 
/*
 * dw0: CT header (including fence)
@@ -453,7 +452,9 @@ static int ct_write(struct intel_guc_ct *ct,
write_barrier(ct);
 
/* now update descriptor */
+   ctb->tail = tail;
WRITE_ONCE(desc->tail, tail);
+   ctb->space -= len + GUC_CTB_HDR_LEN;
 
return 0;
 
@@ -469,7 +470,7 @@ static int ct_write(struct intel_guc_ct *ct,
  * @req:   pointer to pending request
  * @status:placeholder for status
  *
- * For each sent request, Guc shall send bac CT response message.
+ * For each sent request, GuC shall send back CT response message.
  * Our message handler will update status of tracked request once
  * response message with given fence is received. Wait here and
  * check for valid response status value.
@@ -525,24 +526,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct *ct)
return ret;
 }
 
-static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
+static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
 {
-   struct guc_ct_buffer_desc *desc = ctb->desc;
-   u32 head = READ_ONCE(desc->head);
+   struct intel_guc_ct_buffer *ctb = >ctbs.send;
+   u32 head;
u32 space;
 
-   space = CIRC_SPACE(desc->tail, head, ctb->size);
+   if (ctb->space >= len_dw)
+   return true;
+
+   head = READ_ONCE(ctb->desc->head);
+   if (unlikely(head > ctb->size)) {
+   CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u size=%u\n",
+ctb->desc->head, ctb->desc->tail, ctb->size);
+   ctb->desc->status |= GUC_CTB_STATUS_OVERFLOW;
+   ctb->broken = true;
+   return false;
+   }
+
+   space = CIRC_SPACE(ctb->tail, head, ctb->size);
+   ctb->space = space;
 
return space >= len_dw;

Re: [Intel-gfx] [PATCH 0/3] drm/i915: Nuke GEN macros

On Wed, 07 Jul 2021, Lucas De Marchi  wrote:
> Finish the conversion to the new VER macros and nuke the old macros so
> we don't have more changes sneaking in.
>
> Initially I thought about waiting for a backmerge from drm-next in
> drm-intel-next so I could use a topic branch to finish the conversion
> and nuke the macro, merging the topic branch in both drm-intel-next and
> drm-intel-gt-next. After the backmerge landed, I realized that would not
> be possible anymore as we already have changes on top preventing the
> merge-base to be used for a topic branch.
>
> Therefore the plan is:
>   - Apply patch 1 in drm-intel-gt-next
>   - Apply patches 2 and 3 in drm-intel-next
>
> Since patches are tested on drm-tip, CI should flag a build breakage if
> someone uses the GEN macros. Another possibility is to simply apply the
> 3rd patch on both branches, but I don't see a real need for that.

Acked-by: Jani Nikula 


>
> Lucas De Marchi (3):
>   drm/i915/gt: finish INTEL_GEN and friends conversion
>   drm/i915: finish INTEL_GEN and friends conversion
>   gpu/drm/i915: nuke old GEN macros
>
>  .../drm/i915/display/intel_display_debugfs.c  |  3 ++-
>  drivers/gpu/drm/i915/gt/intel_migrate.c   | 20 +--
>  drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h   | 15 --
>  drivers/gpu/drm/i915/intel_uncore.c   |  2 +-
>  5 files changed, 14 insertions(+), 28 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Optimize CTB writes and reads

2021-07-07 Thread John Harrison


On 7/7/2021 10:50, Matthew Brost wrote:

On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:

On 7/6/2021 15:20, Matthew Brost wrote:

CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely necessary. Also store the current space in the each channel
locally.

v2:
   (Michal)
- Add additional sanity checks for head / tail pointers
- Use GUC_CTB_HDR_LEN rather than magic 1
v3:
   (Michal / John H)
- Drop redundant check of head value

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
---
   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 88 +++
   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 ++
   2 files changed, 65 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index db3e85b89573..4a73a1f03a9b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct 
guc_ct_buffer_desc *desc)
   static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
   {
ctb->broken = false;
+   ctb->tail = 0;
+   ctb->head = 0;
+   ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
+
guc_ct_buffer_desc_init(ctb->desc);
   }
@@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
   {
struct intel_guc_ct_buffer *ctb = >ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
-   u32 head = desc->head;
-   u32 tail = desc->tail;
+   u32 tail = ctb->tail;
u32 size = ctb->size;
-   u32 used;
u32 header;
u32 hxg;
u32 type;
@@ -396,25 +398,22 @@ static int ct_write(struct intel_guc_ct *ct,
if (unlikely(desc->status))
goto corrupted;
-   if (unlikely((tail | head) >= size)) {
+   GEM_BUG_ON(tail > size);
+
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
+   if (unlikely(tail != READ_ONCE(desc->tail))) {
+   CT_ERROR(ct, "Tail was modified %u != %u\n",
+desc->tail, ctb->tail);
+   desc->status |= GUC_CTB_STATUS_MISMATCH;
+   goto corrupted;
+   }
+   if (unlikely((desc->tail | desc->head) >= size)) {

Same arguments below about head apply to tail here. Also, there is no #else

Yes, desc->tail can be removed from this check. Same for head below. Can
you fix this when merging?


check on ctb->head?

ctb->head variable isn't used in this path nor is ctb->tail in the
other. In the other path desc->tail is checked as it is read while
desc->head isn't needed to be read here. The other path can also likely
be reworked to pull the tail check outside of the if / else define
block.


CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
-head, tail, size);
+desc->head, desc->tail, size);
desc->status |= GUC_CTB_STATUS_OVERFLOW;
goto corrupted;
}
-
-   /*
-* tail == head condition indicates empty. GuC FW does not support
-* using up the entire buffer to get tail == head meaning full.
-*/
-   if (tail < head)
-   used = (size - head) + tail;
-   else
-   used = tail - head;
-
-   /* make sure there is a space including extra dw for the header */
-   if (unlikely(used + len + GUC_CTB_HDR_LEN >= size))
-   return -ENOSPC;
+#endif
/*
 * dw0: CT header (including fence)
@@ -453,7 +452,9 @@ static int ct_write(struct intel_guc_ct *ct,
write_barrier(ct);
/* now update descriptor */
+   ctb->tail = tail;
WRITE_ONCE(desc->tail, tail);
+   ctb->space -= len + GUC_CTB_HDR_LEN;
return 0;
@@ -469,7 +470,7 @@ static int ct_write(struct intel_guc_ct *ct,
* @req: pointer to pending request
* @status:  placeholder for status
*
- * For each sent request, Guc shall send bac CT response message.
+ * For each sent request, GuC shall send back CT response message.
* Our message handler will update status of tracked request once
* response message with given fence is received. Wait here and
* check for valid response status value.
@@ -525,24 +526,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct *ct)
return ret;
   }
-static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
+static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
   {
-   struct guc_ct_buffer_desc *desc = ctb->desc;
-   u32 head = READ_ONCE(desc->head);
+   struct intel_guc_ct_buffer *ctb = >ctbs.send;
+   u32 head;
u32 space;
-   space = CIRC_SPACE(desc->tail, head, ctb->size);
+   if

[Intel-gfx] [PATCH 3/3] gpu/drm/i915: nuke old GEN macros

Now that all the codebase is converted to the new *VER macros, remove
the old GEN ones.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_drv.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6dff4ca01241..bc6799f75670 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1243,21 +1243,6 @@ static inline struct drm_i915_private 
*pdev_to_i915(struct pci_dev *pdev)
 
 #define INTEL_DEVID(dev_priv)  (RUNTIME_INFO(dev_priv)->device_id)
 
-/*
- * Deprecated: this will be replaced by individual IP checks:
- * GRAPHICS_VER(), MEDIA_VER() and DISPLAY_VER()
- */
-#define INTEL_GEN(dev_priv)GRAPHICS_VER(dev_priv)
-/*
- * Deprecated: use IS_GRAPHICS_VER(), IS_MEDIA_VER() and IS_DISPLAY_VER() as
- * appropriate.
- */
-#define IS_GEN_RANGE(dev_priv, s, e)   IS_GRAPHICS_VER(dev_priv, (s), (e))
-/*
- * Deprecated: use GRAPHICS_VER(), MEDIA_VER() and DISPLAY_VER() as 
appropriate.
- */
-#define IS_GEN(dev_priv, n)(GRAPHICS_VER(dev_priv) == (n))
-
 #define GRAPHICS_VER(i915) (INTEL_INFO(i915)->graphics_ver)
 #define IS_GRAPHICS_VER(i915, from, until) \
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: finish INTEL_GEN and friends conversion

Commit 161058fb899e ("drm/i915: Add remaining conversions to GRAPHICS_VER")
did the last conversions to the new macros for version checks, but some
some changes sneaked in to use INTEL_GEN. Remove the last users so
we can remove the macros.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display_debugfs.c | 3 ++-
 drivers/gpu/drm/i915/i915_debugfs.c  | 2 +-
 drivers/gpu/drm/i915/intel_uncore.c  | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index af9e58619667..d5af5708c9da 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -544,7 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
 
seq_printf(m, "fw loaded: %s\n", 
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
-   seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >= 
12));
+   seq_printf(m, "Pipe A fw support: %s\n",
+  yesno(GRAPHICS_VER(dev_priv) >= 12));
seq_printf(m, "Pipe A fw loaded: %s\n", 
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
seq_printf(m, "Pipe B fw support: %s\n", 
yesno(IS_ALDERLAKE_P(dev_priv)));
seq_printf(m, "Pipe B fw loaded: %s\n", 
yesno(dmc->dmc_info[DMC_FW_PIPEB].payload));
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cc745751ac53..0529576f069c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -636,7 +636,7 @@ static int i915_swizzle_info(struct seq_file *m, void *data)
   intel_uncore_read16(uncore, C0DRB3_BW));
seq_printf(m, "C1DRB3 = 0x%04x\n",
   intel_uncore_read16(uncore, C1DRB3_BW));
-   } else if (INTEL_GEN(dev_priv) >= 6) {
+   } else if (GRAPHICS_VER(dev_priv) >= 6) {
seq_printf(m, "MAD_DIMM_C0 = 0x%08x\n",
   intel_uncore_read(uncore, MAD_DIMM_C0));
seq_printf(m, "MAD_DIMM_C1 = 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index d067524f9162..ee1c6fbc3d97 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1929,7 +1929,7 @@ int intel_uncore_init_mmio(struct intel_uncore *uncore)
return -ENODEV;
}
 
-   if (INTEL_GEN(i915) > 5 && !intel_vgpu_active(i915))
+   if (GRAPHICS_VER(i915) > 5 && !intel_vgpu_active(i915))
uncore->flags |= UNCORE_HAS_FORCEWAKE;
 
if (!intel_uncore_has_forcewake(uncore)) {
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/3] drm/i915: Nuke GEN macros

Finish the conversion to the new VER macros and nuke the old macros so
we don't have more changes sneaking in.

Initially I thought about waiting for a backmerge from drm-next in
drm-intel-next so I could use a topic branch to finish the conversion
and nuke the macro, merging the topic branch in both drm-intel-next and
drm-intel-gt-next. After the backmerge landed, I realized that would not
be possible anymore as we already have changes on top preventing the
merge-base to be used for a topic branch.

Therefore the plan is:
- Apply patch 1 in drm-intel-gt-next
- Apply patches 2 and 3 in drm-intel-next

Since patches are tested on drm-tip, CI should flag a build breakage if
someone uses the GEN macros. Another possibility is to simply apply the
3rd patch on both branches, but I don't see a real need for that.

Lucas De Marchi (3):
  drm/i915/gt: finish INTEL_GEN and friends conversion
  drm/i915: finish INTEL_GEN and friends conversion
  gpu/drm/i915: nuke old GEN macros

 .../drm/i915/display/intel_display_debugfs.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_migrate.c   | 20 +--
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 15 --
 drivers/gpu/drm/i915/intel_uncore.c   |  2 +-
 5 files changed, 14 insertions(+), 28 deletions(-)

-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915/gt: finish INTEL_GEN and friends conversion

Commit c816723b6b8a ("drm/i915/gt: replace IS_GEN and friends with
GRAPHICS_VER") converted INTEL_GEN and friends to the new version check
macros.  Meanwhile, some changes sneaked in to use INTEL_GEN. Remove the
last users so we can remove the macros.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 23c59ce66cee..14afa1974ea5 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -277,7 +277,7 @@ static int emit_pte(struct i915_request *rq,
u32 *hdr, *cs;
int pkt;
 
-   GEM_BUG_ON(INTEL_GEN(rq->engine->i915) < 8);
+   GEM_BUG_ON(GRAPHICS_VER(rq->engine->i915) < 8);
 
/* Compute the page directory offset for the target address range */
offset += (u64)rq->engine->instance << 32;
@@ -347,11 +347,11 @@ static int emit_pte(struct i915_request *rq,
return total;
 }
 
-static bool wa_1209644611_applies(int gen, u32 size)
+static bool wa_1209644611_applies(int ver, u32 size)
 {
u32 height = size >> PAGE_SHIFT;
 
-   if (gen != 11)
+   if (ver != 11)
return false;
 
return height % 4 == 3 && height <= 8;
@@ -359,15 +359,15 @@ static bool wa_1209644611_applies(int gen, u32 size)
 
 static int emit_copy(struct i915_request *rq, int size)
 {
-   const int gen = INTEL_GEN(rq->engine->i915);
+   const int ver = GRAPHICS_VER(rq->engine->i915);
u32 instance = rq->engine->instance;
u32 *cs;
 
-   cs = intel_ring_begin(rq, gen >= 8 ? 10 : 6);
+   cs = intel_ring_begin(rq, ver >= 8 ? 10 : 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   if (gen >= 9 && !wa_1209644611_applies(gen, size)) {
+   if (ver >= 9 && !wa_1209644611_applies(ver, size)) {
*cs++ = GEN9_XY_FAST_COPY_BLT_CMD | (10 - 2);
*cs++ = BLT_DEPTH_32 | PAGE_SIZE;
*cs++ = 0;
@@ -378,7 +378,7 @@ static int emit_copy(struct i915_request *rq, int size)
*cs++ = PAGE_SIZE;
*cs++ = 0; /* src offset */
*cs++ = instance;
-   } else if (gen >= 8) {
+   } else if (ver >= 8) {
*cs++ = XY_SRC_COPY_BLT_CMD | BLT_WRITE_RGBA | (10 - 2);
*cs++ = BLT_DEPTH_32 | BLT_ROP_SRC_COPY | PAGE_SIZE;
*cs++ = 0;
@@ -491,17 +491,17 @@ intel_context_migrate_copy(struct intel_context *ce,
 
 static int emit_clear(struct i915_request *rq, int size, u32 value)
 {
-   const int gen = INTEL_GEN(rq->engine->i915);
+   const int ver = GRAPHICS_VER(rq->engine->i915);
u32 instance = rq->engine->instance;
u32 *cs;
 
GEM_BUG_ON(size >> PAGE_SHIFT > S16_MAX);
 
-   cs = intel_ring_begin(rq, gen >= 8 ? 8 : 6);
+   cs = intel_ring_begin(rq, ver >= 8 ? 8 : 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   if (gen >= 8) {
+   if (ver >= 8) {
*cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (7 - 2);
*cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
*cs++ = 0;
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Optimize CTB writes and reads

On Tue, Jul 06, 2021 at 03:51:00PM -0700, John Harrison wrote:
> On 7/6/2021 15:20, Matthew Brost wrote:
> > CTB writes are now in the path of command submission and should be
> > optimized for performance. Rather than reading CTB descriptor values
> > (e.g. head, tail) which could result in accesses across the PCIe bus,
> > store shadow local copies and only read/write the descriptor values when
> > absolutely necessary. Also store the current space in the each channel
> > locally.
> > 
> > v2:
> >   (Michal)
> >- Add additional sanity checks for head / tail pointers
> >- Use GUC_CTB_HDR_LEN rather than magic 1
> > v3:
> >   (Michal / John H)
> >- Drop redundant check of head value
> > 
> > Signed-off-by: John Harrison 
> > Signed-off-by: Matthew Brost 
> > ---
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 88 +++
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 ++
> >   2 files changed, 65 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index db3e85b89573..4a73a1f03a9b 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct 
> > guc_ct_buffer_desc *desc)
> >   static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> >   {
> > ctb->broken = false;
> > +   ctb->tail = 0;
> > +   ctb->head = 0;
> > +   ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
> > +
> > guc_ct_buffer_desc_init(ctb->desc);
> >   }
> > @@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
> >   {
> > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > -   u32 head = desc->head;
> > -   u32 tail = desc->tail;
> > +   u32 tail = ctb->tail;
> > u32 size = ctb->size;
> > -   u32 used;
> > u32 header;
> > u32 hxg;
> > u32 type;
> > @@ -396,25 +398,22 @@ static int ct_write(struct intel_guc_ct *ct,
> > if (unlikely(desc->status))
> > goto corrupted;
> > -   if (unlikely((tail | head) >= size)) {
> > +   GEM_BUG_ON(tail > size);
> > +
> > +#ifdef CONFIG_DRM_I915_DEBUG_GUC
> > +   if (unlikely(tail != READ_ONCE(desc->tail))) {
> > +   CT_ERROR(ct, "Tail was modified %u != %u\n",
> > +desc->tail, ctb->tail);
> > +   desc->status |= GUC_CTB_STATUS_MISMATCH;
> > +   goto corrupted;
> > +   }
> > +   if (unlikely((desc->tail | desc->head) >= size)) {
> Same arguments below about head apply to tail here. Also, there is no #else

Yes, desc->tail can be removed from this check. Same for head below. Can
you fix this when merging?

> check on ctb->head?

ctb->head variable isn't used in this path nor is ctb->tail in the
other. In the other path desc->tail is checked as it is read while
desc->head isn't needed to be read here. The other path can also likely
be reworked to pull the tail check outside of the if / else define
block.

> 
> > CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> > -head, tail, size);
> > +desc->head, desc->tail, size);
> > desc->status |= GUC_CTB_STATUS_OVERFLOW;
> > goto corrupted;
> > }
> > -
> > -   /*
> > -* tail == head condition indicates empty. GuC FW does not support
> > -* using up the entire buffer to get tail == head meaning full.
> > -*/
> > -   if (tail < head)
> > -   used = (size - head) + tail;
> > -   else
> > -   used = tail - head;
> > -
> > -   /* make sure there is a space including extra dw for the header */
> > -   if (unlikely(used + len + GUC_CTB_HDR_LEN >= size))
> > -   return -ENOSPC;
> > +#endif
> > /*
> >  * dw0: CT header (including fence)
> > @@ -453,7 +452,9 @@ static int ct_write(struct intel_guc_ct *ct,
> > write_barrier(ct);
> > /* now update descriptor */
> > +   ctb->tail = tail;
> > WRITE_ONCE(desc->tail, tail);
> > +   ctb->space -= len + GUC_CTB_HDR_LEN;
> > return 0;
> > @@ -469,7 +470,7 @@ static int ct_write(struct intel_guc_ct *ct,
> >* @req:  pointer to pending request
> >* @status:   placeholder for status
> >*
> > - * For each sent request, Guc shall send bac CT response message.
> > + * For each sent request, GuC shall send back CT response message.
> >* Our message handler will update status of tracked request once
> >* response message with given fence is received. Wait here and
> >* check for valid response status value.
> > @@ -525,24 +526,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct 
> > *ct)
> > return ret;
> >   }
> > -static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 
> > len_dw)
> > +static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
> >   {
> > -   struct guc_ct_buffer_desc *desc = ctb->desc;
> > -   u32 head =

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_s: Fix dma_mask_size to 39 bit (rev2)

== Series Details ==

Series: drm/i915/adl_s: Fix dma_mask_size to 39 bit (rev2)
URL   : https://patchwork.freedesktop.org/series/92262/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309_full -> Patchwork_20544_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- {shard-rkl}:[SKIP][1] ([i915#3721]) -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-rkl-2/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-rkl-6/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs:
- {shard-rkl}:[FAIL][3] ([i915#3678]) -> [SKIP][4] +3 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-rkl-1/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-rkl-6/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html

  * igt@kms_flip_tiling@flip-changes-tiling-y:
- {shard-rkl}:NOTRUN -> [SKIP][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-rkl-5/igt@kms_flip_til...@flip-changes-tiling-y.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html

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

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_fence@basic-wait@bcs0:
- shard-kbl:  NOTRUN -> [SKIP][16] ([fdo#109271]) +63 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-kbl3/igt@gem_exec_fence@basic-w...@bcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-snb:  NOTRUN -> [SKIP][17] ([fdo#109271]) +359 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-snb2/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_params@no-blt:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-iclb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_reloc@basic-wide-active@bcs0:
- shard-apl:  NOTRUN -> [FAIL][19] ([i915#3633]) +3 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/shard-apl2/igt@gem_exec_reloc@basic-wide-act...@bcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][20] ([i915#3633]) +2 similar issues
   [20]:

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drivers/gpu/drm/i915/gt/intel_engine_cs.c: Repair typo in function name

== Series Details ==

Series: series starting with [1/2] drivers/gpu/drm/i915/gt/intel_engine_cs.c: 
Repair typo in function name
URL   : https://patchwork.freedesktop.org/series/92273/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10309_full -> Patchwork_20543_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- shard-snb:  NOTRUN -> [DMESG-WARN][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-snb7/igt@core_hotunp...@unbind-rebind.html

  
 Warnings 

  * igt@runner@aborted:
- shard-snb:  ([FAIL][2], [FAIL][3]) ([i915#3002]) -> ([FAIL][4], 
[FAIL][5], [FAIL][6], [FAIL][7]) ([i915#2722] / [i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-snb5/igt@run...@aborted.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-snb5/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-snb6/igt@run...@aborted.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-snb2/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-snb2/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-snb7/igt@run...@aborted.html

  
 Suppressed 

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

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- {shard-rkl}:[SKIP][8] ([i915#3721]) -> [DMESG-WARN][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-rkl-2/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-rkl-6/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html

  * igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs:
- {shard-rkl}:[FAIL][10] ([i915#3678]) -> [SKIP][11] +3 similar 
issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-rkl-1/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-rkl-6/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html

  * igt@kms_flip_tiling@flip-changes-tiling-y:
- {shard-rkl}:NOTRUN -> [SKIP][12]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-rkl-2/igt@kms_flip_til...@flip-changes-tiling-y.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][15] -> [TIMEOUT][16] ([i915#2369] / 
[i915#2481] / [i915#3070])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-iclb8/igt@gem_...@unwedge-stress.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-iclb5/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@persistence:
- shard-glk:  [PASS][17] -> [DMESG-WARN][18] ([i915#118] / 
[i915#95])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-glk2/igt@gem_exec_balan...@persistence.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-glk2/igt@gem_exec_balan...@persistence.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#2842])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl:  [PASS][21] -> [FAIL][22] ([i915#2842])
   [21]:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: Rework CFB stride/size calculations (rev2)

== Series Details ==

Series: drm/i915/fbc: Rework CFB stride/size calculations (rev2)
URL   : https://patchwork.freedesktop.org/series/92163/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309 -> Patchwork_20545


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u:   [PASS][1] -> [DMESG-FAIL][2] ([i915#165])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-tgl-1115g4}:[FAIL][3] ([i915#1888]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][5] ([i915#1372]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

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

  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10309 -> Patchwork_20545

  CI-20190529: 20190529
  CI_DRM_10309: 6a5db0d08c45a29cebcfd39b53a15be664b9369c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6130: 390edfb703c346f06b0850db71bd3cc1342a3c02 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20545: 0185143ee826d212fa71169f94eb876a7d72b293 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0185143ee826 drm/i915/fbc: Allow higher compression limits on FBC1
1091564c7004 drm/i915/fbc: Implement Wa_16011863758 for icl+
29df4825d9dd drm/i915/fbc: Align FBC segments to 512B on glk+
69bbbd1d9aae drm/i915/fbc: Rework cfb stride/size calculations
270422b7c7b2 drm/i915/fbc: Polish the skl+ FBC stride override handling
81c9ecdfa371 drm/i915/fbc: Move the "recompress on activate" to a central place
dee78ea53693 drm/i915/fbc: Extract intel_fbc_update()
0b6c118b349e drm/i915/fbc: Rewrite the FBC tiling check a bit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20545/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/53] drm/i915: Fork DG1 interrupt handler

On Wed, Jul 07, 2021 at 09:39:03AM +0200, Daniel Vetter wrote:

On Wed, Jul 7, 2021 at 12:48 AM Lucas De Marchi
 wrote:

On Fri, Jul 02, 2021 at 11:21:10AM +0200, Daniel Vetter wrote:
>On Thu, Jul 1, 2021 at 10:26 PM Matt Roper  wrote:
>>
>> From: Paulo Zanoni 
>>
>> The current interrupt handler is getting increasingly complicated and
>> Xe_HP changes will bring even more complexity.  Let's split off a new
>> interrupt handler starting with DG1 (i.e., when the master tile
>> interrupt register was added to the design) and use that as the basis
>> for the new Xe_HP changes.
>>
>> Now that we track the hardware IP's release number as well as the
>> version number, we can also properly define DG1 has version "12.10" and
>> replace the has_master_unit_irq feature flag with an IP version test.
>>
>> Bspec: 50875
>> Cc: Daniele Spurio Ceraolo 
>> Cc: Stuart Summers 
>> Signed-off-by: Paulo Zanoni 
>> Signed-off-by: Lucas De Marchi 
>> Signed-off-by: Tomasz Lis 
>> Signed-off-by: Matt Roper 
>
>So I know DG1 upstream is decidedly non-smooth, but basic
>infrastructure we've had since forever ...
>
>Why was this prep work not upstreamed earlier with some benign commit
>message that doesn't mention DG2? There's zero DG2 stuff in here, this
>could have landed months/years ago even. Bringing this up since right
>this moment we have an internal chat about trees diverging a bit much.

history isn't linear and this commit, the way it is now, didn't exist 1
month ago, so your timescale is misleading. has_master_unit_irq was what
we thought we would need to share as much code as possible.

The biggest reason to fork the irq handler is actually not DG1 nor DG2,
but XEHPSDV and without those changes it would basically be a 95% copy
of the gen11 handler... for someone not looking to what is in the
pipeline, it can be a perfect argument to "consolidate these into a
single handler".

At least in the past we've done tons of upstream refactor prep for
exactly just these "prep for future platform" reasons. Everyone
understand that's necessary and generally trusts us we're not just
moving code for fun. But then 1-2 years ago we just kinda stopped
pushing prep work to upstream because everyone got way too busy with
other things, and now we're paying the price.

we both know this is not the only reason and looking to the people in Cc
here my impression is you're preaching to the choir. Because the people
in Cc here either moved to other teams before there was something
working related to irq to share or continued to do prep work in upstream
as much as they can. 

Lucas De Marchi

I mean even if the reason to fork it is a platform we can't even talk
about, the fork patch should go upstream way ahead so that there's
less patches in internal. Ideally platform enabling is zero code
shuffling, 100% just plugging code into existing neat places.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/53] drm/i915: Add "release id" version


On Wed, Jul 07, 2021 at 11:34:36AM +0300, Jani Nikula wrote:

On Tue, 06 Jul 2021, Lucas De Marchi  wrote:

On Mon, Jul 05, 2021 at 02:52:31PM +0300, Jani Nikula wrote:

On Fri, 02 Jul 2021, Tvrtko Ursulin  wrote:

On 01/07/2021 21:23, Matt Roper wrote:

From: Lucas De Marchi 

Besides the arch version returned by GRAPHICS_VER(), new platforms
contain a "release id" to make clear the difference from one platform to
another. Although for the first ones we may use them as if they were a


What does "first ones" refer to here?


major/minor version, that is not true for all platforms: we may have a
`release_id == n` that is closer to `n - 2` than to `n - 1`.


Hm this is a bit confusing. Is the sentence simply trying to say that,
as the release id number is growing, hw capabilities are not simply
accumulating but can be removed as well? Otherwise I am not sure how the
user of these macros is supposed to act on this sentence.


However the release id number is not defined by hardware until we start
using the GMD_ID register. For the platforms before that register is
useful we will set the values in software and we can set them as we
please. So the plan is to set them so we can group different features
under a single GRAPHICS_VER_FULL() check.

After GMD_ID is used, the usefulness of a "full version check" will be
greatly reduced and will be mostly used for deciding workarounds and a
few code paths. So it makes sense to keep it as a separate field from
graphics_ver.

Also, currently there is not much use for the release id in media and
display, so keep them out.

This is a mix of 2 independent changes: one by me and the other by Matt
Roper.

Cc: Matt Roper 
Signed-off-by: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/i915_drv.h  | 6 ++
  drivers/gpu/drm/i915/intel_device_info.c | 2 ++
  drivers/gpu/drm/i915/intel_device_info.h | 2 ++
  3 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6dff4ca01241..9639800485b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1258,11 +1258,17 @@ static inline struct drm_i915_private 
*pdev_to_i915(struct pci_dev *pdev)
   */
  #define IS_GEN(dev_priv, n)   (GRAPHICS_VER(dev_priv) == (n))

+#define IP_VER(ver, release)   ((ver) << 8 | (release))
+
  #define GRAPHICS_VER(i915)(INTEL_INFO(i915)->graphics_ver)
+#define GRAPHICS_VER_FULL(i915)
IP_VER(INTEL_INFO(i915)->graphics_ver, \
+  
INTEL_INFO(i915)->graphics_ver_release)
  #define IS_GRAPHICS_VER(i915, from, until) \
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))

  #define MEDIA_VER(i915)   (INTEL_INFO(i915)->media_ver)
+#define MEDIA_VER_FULL(i915)   IP_VER(INTEL_INFO(i915)->media_ver, \
+  
INTEL_INFO(i915)->media_ver_release)
  #define IS_MEDIA_VER(i915, from, until) \
(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 7eaa92fee421..e8ad14f002c1 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -97,7 +97,9 @@ void intel_device_info_print_static(const struct 
intel_device_info *info,
struct drm_printer *p)
  {
drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);
+   drm_printf(p, "graphics_ver_release: %u\n", info->graphics_ver_release);


I get the VER and VER_FULL in the macros but could 'ver' and
'ver_release' here and in the code simply be renamed to 'ver'/'version'
and 'release'? Maybe it is just me but don't think I encountered the
term "version release" before.


Just bikeshedding here, but I thought of:

if (info->grapics_ver_release)
drm_printf(p, "graphics_ver: %u.%u\n", info->graphics_ver, 
info->graphics_ver_release);
else
drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);


humn... a suggestion that I got internally a few week ago and I forgot
to update this was that this doesn't need to be abbreviated in debugfs
and could very well be:

drm_printf(p, "graphics version: %u\n", info->graphics_ver);
drm_printf(p, "graphics release: %u\n", info->graphics_ver_release);


Also, I thought "x_ver" and "x_ver_release" sounds a bit odd, perhaps
having "x_ver" and "x_rel" is more natural?


Not sure what direction to go now though. Maybe trying to put all
suggestions together:

if (info->graphics_rel)
drm_printf(p, "graphics version: %u.%u\n", info->graphics_ver, 
info->graphics_rel);
else
drm_printf(p, "graphics version: %u\n", info->graphics_ver);

One thing  I like is that doing `| grep "graphics version"`
gives all info you are searching for.


I'd like

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/fbc: Rework CFB stride/size calculations (rev2)

== Series Details ==

Series: drm/i915/fbc: Rework CFB stride/size calculations (rev2)
URL   : https://patchwork.freedesktop.org/series/92163/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts

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

2021-07-07 Thread Rodrigo Vivi

Hi Dave and Daniel,

Here goes drm-intel-next-fixes-2021-07-07:

One fix targeting stable for display DP VSC, plus DG1 display fix and
a bug fix of IRQs usages and cleanup references to the DRM IRQ midlayer.

Thanks,
Rodrigo.

The following changes since commit 8a02ea42bc1d4c448caf1bab0e05899dad503f74:

  Merge tag 'drm-intel-next-fixes-2021-06-29' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-06-30 15:42:05 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2021-07-07

for you to fetch changes up to 3dd6c11b60d2f1e4082221a8831f91093c4494aa:

  drm/i915: Drop all references to DRM IRQ midlayer (2021-07-06 15:10:58 -0400)


One fix targeting stable for display DP VSC, plus DG1 display fix and
a bug fix of IRQs usages and cleanup references to the DRM IRQ midlayer.


José Roberto de Souza (1):
  drm/i915/display/dg1: Correctly map DPLLs during state readout

Kees Cook (1):
  drm/i915/display: Do not zero past infoframes.vsc

Thomas Zimmermann (2):
  drm/i915: Use the correct IRQ during resume
  drm/i915: Drop all references to DRM IRQ midlayer

 drivers/gpu/drm/i915/display/intel_ddi.c| 19 ---
 drivers/gpu/drm/i915/display/intel_dp.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_ring_submission.c |  7 +--
 drivers/gpu/drm/i915/i915_drv.c |  1 -
 drivers/gpu/drm/i915/i915_irq.c | 10 +-
 drivers/gpu/drm/i915/i915_irq.h |  1 +
 drivers/gpu/drm/i915/i915_reg.h |  3 ---
 8 files changed, 29 insertions(+), 16 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_s: Fix dma_mask_size to 39 bit (rev2)

== Series Details ==

Series: drm/i915/adl_s: Fix dma_mask_size to 39 bit (rev2)
URL   : https://patchwork.freedesktop.org/series/92262/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309 -> Patchwork_20544


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-tgl-1115g4}:[FAIL][1] ([i915#1888]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][3] ([i915#1372]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

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

  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888


Participating hosts (44 -> 39)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 


Build changes
-

  * Linux: CI_DRM_10309 -> Patchwork_20544

  CI-20190529: 20190529
  CI_DRM_10309: 6a5db0d08c45a29cebcfd39b53a15be664b9369c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6130: 390edfb703c346f06b0850db71bd3cc1342a3c02 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20544: b8b5ed4b051951d47f9f8321758d7e31ac25132e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b8b5ed4b0519 drm/i915/adl_s: Fix dma_mask_size to 39 bit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20544/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adl_s: Fix dma_mask_size to 39 bit (rev2)

== Series Details ==

Series: drm/i915/adl_s: Fix dma_mask_size to 39 bit (rev2)
URL   : https://patchwork.freedesktop.org/series/92262/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b8b5ed4b0519 drm/i915/adl_s: Fix dma_mask_size to 39 bit
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#18: 
In a way solves Gitlab#3142 
https://gitlab.freedesktop.org/drm/intel/-/issues/3142,

-:19: WARNING:TYPO_SPELLING: 'follwing' may be misspelled - perhaps 'following'?
#19: 
which had follwing errors :
  

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


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drivers/gpu/drm/i915/gt/intel_engine_cs.c: Repair typo in function name

== Series Details ==

Series: series starting with [1/2] drivers/gpu/drm/i915/gt/intel_engine_cs.c: 
Repair typo in function name
URL   : https://patchwork.freedesktop.org/series/92273/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10309 -> Patchwork_20543


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-cfl-8109u:   NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/fi-cfl-8109u/igt@kms_chamel...@hdmi-hpd-fast.html

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

  * igt@kms_psr@primary_mmap_gtt:
- fi-cfl-8109u:   NOTRUN -> [SKIP][4] ([fdo#109271]) +6 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/fi-cfl-8109u/igt@kms_psr@primary_mmap_gtt.html

  * igt@runner@aborted:
- fi-cfl-8109u:   NOTRUN -> [FAIL][5] ([i915#2722] / [i915#3363])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/fi-cfl-8109u/igt@run...@aborted.html

  * igt@vgem_basic@unload:
- fi-cfl-8109u:   NOTRUN -> [INCOMPLETE][6] ([i915#3744])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/fi-cfl-8109u/igt@vgem_ba...@unload.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u:   [INCOMPLETE][7] ([i915#155]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
- {fi-tgl-1115g4}:[FAIL][9] ([i915#1888]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][11] ([i915#1372]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10309/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.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#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3744]: https://gitlab.freedesktop.org/drm/intel/issues/3744
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (44 -> 40)
--

  Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10309 -> Patchwork_20543

  CI-20190529: 20190529
  CI_DRM_10309: 6a5db0d08c45a29cebcfd39b53a15be664b9369c @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6130: 390edfb703c346f06b0850db71bd3cc1342a3c02 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20543: 839f1195018f60c40d8eb75a8eb98bf5679c910e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

839f1195018f drivers/gpu/drm/i915/display/intel_display_power.c: Repair typo in 
function name
1ffae15fec63 drivers/gpu/drm/i915/gt/intel_engine_cs.c: Repair typo in function 
name

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20543/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH V2] drm/i915/adl_s: Fix dma_mask_size to 39 bit

2021-07-07 Thread Tejas Upadhyay

46 bit addressing enables you to use 4 bits  to support some
MKTME features, and 3 more bits for Optane support that uses
a subset of MTKME for persistent memory.

But GTT addressing sticking to 39 bit addressing, thus setting
dma_mask_size to 39 fixes below tests :
igt@i915_selftest@live@mman
igt@kms_big_fb@linear-32bpp-rotate-0
igt@gem_create@create-clear
igt@gem_mmap_offset@clear
igt@gem_mmap_gtt@cpuset-big-copy

In a way solves Gitlab#3142 
https://gitlab.freedesktop.org/drm/intel/-/issues/3142,
which had follwing errors :
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [00:02.0] PASID  fault addr
7e9000 [fault reason 05] PTE Write access is not set

0x7e9000 is suspiciously exactly 39 bits, so it seems likely that
the HW just ends up masking off those extra bits hence DMA errors.

Changes since V1 :
- Added more details to commit message - Matthew Auld

Signed-off-by: Tejas Upadhyay 
Acked-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a7bfdd827bc8..0fea4c0c6d48 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -934,7 +934,7 @@ static const struct intel_device_info adl_s_info = {
.display.has_psr_hw_tracking = 0,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
-   .dma_mask_size = 46,
+   .dma_mask_size = 39,
 };
 
 #define XE_LPD_CURSOR_OFFSETS \
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/etnaviv: Don't break exclusive fence ordering

On Wed, Jul 7, 2021 at 2:31 PM Lucas Stach  wrote:
>
> Am Mittwoch, dem 07.07.2021 um 13:37 +0200 schrieb Daniel Vetter:
> > On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach  wrote:
> > >
> > > Hi Daniel,
> > >
> > > I'm feeling like I miss a ton of context here, so some maybe dumb
> > > questions/remarks below.
> > >
> > > Am Dienstag, dem 06.07.2021 um 12:12 +0200 schrieb Daniel Vetter:
> > > > There's only one exclusive slot, and we must not break the ordering.
> > > >
> > > > A better fix would be to us a dma_fence_chain or _array like e.g.
> > > > amdgpu now uses, but it probably makes sense to lift this into
> > > > dma-resv.c code as a proper concept, so that drivers don't have to
> > > > hack up their own solution each on their own. Hence go with the simple
> > > > fix for now.
> > > >
> > > > Another option is the fence import ioctl from Jason:
> > > >
> > > > https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
> > >
> > > Sorry, but why is the fence import ioctl a alternative to the fix
> > > proposed in this patch?
> >
> > It's not an alternative to fixing the issue here, it's an alternative
> > to trying to fix this here without adding more dependencies. Depends a
> > bit what exactly you want to do, I just linked this for the bigger
> > picture.
> >
> I appreciate the bigger picture, it just makes it harder to follow what
> is going on in this exact commit when trying to match up the code
> change with the commit message. I would have expected this link to only
> be part of the cover letter explaining the series, instead of being
> part of the commit message.

I wanted to list all the better fix options in the commit message so
that you have the full context.

> > > >
> > > > Signed-off-by: Daniel Vetter 
> > > > Cc: Lucas Stach 
> > > > Cc: Russell King 
> > > > Cc: Christian Gmeiner 
> > > > Cc: etna...@lists.freedesktop.org
> > > > ---
> > > >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +---
> > > >  1 file changed, 5 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> > > > b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > > > index 92478a50a580..5c4fed2b7c6a 100644
> > > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > > > @@ -178,18 +178,20 @@ static int submit_fence_sync(struct 
> > > > etnaviv_gem_submit *submit)
> > > >   for (i = 0; i < submit->nr_bos; i++) {
> > > >   struct etnaviv_gem_submit_bo *bo = >bos[i];
> > > >   struct dma_resv *robj = bo->obj->base.resv;
> > > > + bool write = bo->flags & ETNA_SUBMIT_BO_WRITE;
> > > >
> > > > - if (!(bo->flags & ETNA_SUBMIT_BO_WRITE)) {
> > > > + if (!(write)) {
> > >
> > > No parenthesis around the write needed.
> > >
> > > >   ret = dma_resv_reserve_shared(robj, 1);
> > > >   if (ret)
> > > >   return ret;
> > > >   }
> > > >
> > > > - if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
> > > > + /* exclusive fences must be ordered */
> > >
> > > I feel like this comment isn't really helpful. It might tell you all
> > > you need to know if you just paged in all the context around dma_resv
> > > and the dependency graph, but it's not more than noise to me right now.
> > >
> > > I guess the comment should answer the question against what the
> > > exclusive fence we are going to add needs to be ordered and why it
> > > isn't safe to skip implicit sync in that case.
> >
> > The full-length comment is the doc patch, which is last in the series.
> > Essentially the rule is that your not allowed to drop fences on the
> > floor (which you do if you just set a new write fence and not take any
> > of the existing fences as dependencies), at least for shared buffers.
> > But since it's easier to be consistent I think it's best if we do this
> > just across the board.
> >
> > Like the commit message explains, there's a few ways to fix this:
> > - just treat it as implicit synced
> > - chain the fences together - that way you don't sync, but also
> > there's no fence that's being lost. This is what amdgpu does, and also
> > what the new import ioctl does.
> >
> > 2nd option is a lot more involved, and since all the dma-resv stuff is
> > a bit under discussion, I went with the most minimal thing possible.
>
> Thanks for the confirmation, that was as much as I figured from the doc
> patch as well. So with that in mind I would expect this comment to read
> something like this:
> "Adding a new exclusive fence drops all previous fences from the
> dma_resv. To avoid violating the signalling order we err on the side of
> over-synchronizing by waiting for the existing fences, even if
> userspace asked us to ignore them."

Thanks for the suggestion, I've applied that to all the 3 patches for
msm/etnaviv and i915.

I hope with that added there's

Re: [Intel-gfx] [PATCH] drm/i915/adl_s: Fix dma_mask_size to 39 bit

2021-07-07 Thread Surendrakumar Upadhyay, TejaskumarX




> -Original Message-
> From: Matthew Auld 
> Sent: 07 July 2021 15:45
> To: Surendrakumar Upadhyay, TejaskumarX
> 
> Cc: Intel Graphics Development 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/adl_s: Fix dma_mask_size to 39 bit
> 
> On Wed, 7 Jul 2021 at 09:31, Tejas Upadhyay
>  wrote:
> >
> > 46 bit addressing enables you to use 4 bits  to support some MKTME
> > features, and 3 more bits for Optane support that uses a subset of
> > MTKME for persistent memory.
> >
> > But display sticking to 39 bit addressing, thus setting dma_mask_size
> 
> What is meant by "display" here? Is this limited to the display part of the
> HW? Or just in general any HW access via GGTT or ppGTT?
> 

I am really not sure of in general, but all tests which were failing with 
intel_iommu=on and passing with off, are happy with 39 bit addressing. 

> Also do you know if this is documented somewhere in the Bspec? If so,
> adding Bspec: link would be good.

Bspec link does not show this, but there is HSD which gives information. 
Unfortunately not able to share HSD link in this forum. I have copied info from 
HSD only.
I will also try to add additional details in commit message.  

> 
> > to 39 fixes below tests :
> > igt@i915_selftest@live@mman
> > kms_big_fb --r linear-32bpp-rotate-0
> 
> This looks promising. From chatting with Chris it looks like this is
> https://gitlab.freedesktop.org/drm/intel/-/issues/3142 ?
> 
> If so, it might be good to add a References: tag and add the following
> example to the commit message:
> 
> DMAR: DRHD: handling fault status reg 2
> DMAR: [DMA Write] Request device [00:02.0] PASID  fault addr
> 7e9000 [fault reason 05] PTE Write access is not set
> 
> Also maybe highlight that the address 0x7e9000 is suspiciously exactly 39
> bits, so it seems likely that the HW just ends up masking off those extra bits
> or something when doing the access, hence why we might see strange DMAR
> errors?
> 

Sure I will add this.

Thanks,
Tejas
> Nice find,
> Acked-by: Matthew Auld 
> 
> >
> > Signed-off-by: Tejas Upadhyay
> > 
> > ---
> >  drivers/gpu/drm/i915/i915_pci.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c index a7bfdd827bc8..0fea4c0c6d48
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -934,7 +934,7 @@ static const struct intel_device_info adl_s_info = {
> > .display.has_psr_hw_tracking = 0,
> > .platform_engine_mask =
> > BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
> > -   .dma_mask_size = 46,
> > +   .dma_mask_size = 39,
> >  };
> >
> >  #define XE_LPD_CURSOR_OFFSETS \
> > --
> > 2.31.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/etnaviv: Don't break exclusive fence ordering

2021-07-07 Thread Lucas Stach

Am Mittwoch, dem 07.07.2021 um 13:37 +0200 schrieb Daniel Vetter:
> On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach  wrote:
> > 
> > Hi Daniel,
> > 
> > I'm feeling like I miss a ton of context here, so some maybe dumb
> > questions/remarks below.
> > 
> > Am Dienstag, dem 06.07.2021 um 12:12 +0200 schrieb Daniel Vetter:
> > > There's only one exclusive slot, and we must not break the ordering.
> > > 
> > > A better fix would be to us a dma_fence_chain or _array like e.g.
> > > amdgpu now uses, but it probably makes sense to lift this into
> > > dma-resv.c code as a proper concept, so that drivers don't have to
> > > hack up their own solution each on their own. Hence go with the simple
> > > fix for now.
> > > 
> > > Another option is the fence import ioctl from Jason:
> > > 
> > > https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
> > 
> > Sorry, but why is the fence import ioctl a alternative to the fix
> > proposed in this patch?
> 
> It's not an alternative to fixing the issue here, it's an alternative
> to trying to fix this here without adding more dependencies. Depends a
> bit what exactly you want to do, I just linked this for the bigger
> picture.
> 
I appreciate the bigger picture, it just makes it harder to follow what
is going on in this exact commit when trying to match up the code
change with the commit message. I would have expected this link to only
be part of the cover letter explaining the series, instead of being
part of the commit message.

> 
> > 
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Lucas Stach 
> > > Cc: Russell King 
> > > Cc: Christian Gmeiner 
> > > Cc: etna...@lists.freedesktop.org
> > > ---
> > >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +---
> > >  1 file changed, 5 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> > > b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > > index 92478a50a580..5c4fed2b7c6a 100644
> > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > > @@ -178,18 +178,20 @@ static int submit_fence_sync(struct 
> > > etnaviv_gem_submit *submit)
> > >   for (i = 0; i < submit->nr_bos; i++) {
> > >   struct etnaviv_gem_submit_bo *bo = >bos[i];
> > >   struct dma_resv *robj = bo->obj->base.resv;
> > > + bool write = bo->flags & ETNA_SUBMIT_BO_WRITE;
> > > 
> > > - if (!(bo->flags & ETNA_SUBMIT_BO_WRITE)) {
> > > + if (!(write)) {
> > 
> > No parenthesis around the write needed.
> > 
> > >   ret = dma_resv_reserve_shared(robj, 1);
> > >   if (ret)
> > >   return ret;
> > >   }
> > > 
> > > - if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
> > > + /* exclusive fences must be ordered */
> > 
> > I feel like this comment isn't really helpful. It might tell you all
> > you need to know if you just paged in all the context around dma_resv
> > and the dependency graph, but it's not more than noise to me right now.
> > 
> > I guess the comment should answer the question against what the
> > exclusive fence we are going to add needs to be ordered and why it
> > isn't safe to skip implicit sync in that case.
> 
> The full-length comment is the doc patch, which is last in the series.
> Essentially the rule is that your not allowed to drop fences on the
> floor (which you do if you just set a new write fence and not take any
> of the existing fences as dependencies), at least for shared buffers.
> But since it's easier to be consistent I think it's best if we do this
> just across the board.
> 
> Like the commit message explains, there's a few ways to fix this:
> - just treat it as implicit synced
> - chain the fences together - that way you don't sync, but also
> there's no fence that's being lost. This is what amdgpu does, and also
> what the new import ioctl does.
> 
> 2nd option is a lot more involved, and since all the dma-resv stuff is
> a bit under discussion, I went with the most minimal thing possible.

Thanks for the confirmation, that was as much as I figured from the doc
patch as well. So with that in mind I would expect this comment to read
something like this:
"Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore them."

Regards,
Lucas

> -Daniel
> 
> > 
> > Regards,
> > Lucas
> > > + if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT && !write)
> > >   continue;
> > > 
> > >   ret = drm_sched_job_await_implicit(>sched_job, 
> > > >obj->base,
> > > -bo->flags & 
> > > ETNA_SUBMIT_BO_WRITE);
> > > +write);
> > >   if (ret)

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: use consistent CPU mappings for pin_map users

On Mon, Jul 05, 2021 at 02:53:06PM +0100, Matthew Auld wrote:
> For discrete, users of pin_map() needs to obey the same rules at the TTM
> backend, where we map system only objects as WB, and everything else as
> WC. The simplest for now is to just force the correct mapping type as
> per the new rules for discrete.
> 
> Suggested-by: Thomas Hellström 
> Signed-off-by: Matthew Auld 
> Cc: Thomas Hellström 
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Ramalingam C 

Huge thanks for doing all the kerneldoc work for uapi you're doing in this
series, this should help a lot with umd conversions since we can just
point them at the docs and tell them to pls update code.

Yes I know there's no kerneldoc here, but I didn't see the cover letter
:-)

Cheers, Daniel

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c | 34 ++
>  drivers/gpu/drm/i915/gem/i915_gem_object.h |  4 +++
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c  | 22 --
>  3 files changed, 58 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 547cc9dad90d..9da7b288b7ed 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -625,6 +625,40 @@ int i915_gem_object_migrate(struct drm_i915_gem_object 
> *obj,
>   return obj->ops->migrate(obj, mr);
>  }
>  
> +/**
> + * i915_gem_object_placement_possible - Check whether the object can be
> + * placed at certain memory type
> + * @obj: Pointer to the object
> + * @type: The memory type to check
> + *
> + * Return: True if the object can be placed in @type. False otherwise.
> + */
> +bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
> + enum intel_memory_type type)
> +{
> + unsigned int i;
> +
> + if (!obj->mm.n_placements) {
> + switch (type) {
> + case INTEL_MEMORY_LOCAL:
> + return i915_gem_object_has_iomem(obj);
> + case INTEL_MEMORY_SYSTEM:
> + return i915_gem_object_has_pages(obj);
> + default:
> + /* Ignore stolen for now */
> + GEM_BUG_ON(1);
> + return false;
> + }
> + }
> +
> + for (i = 0; i < obj->mm.n_placements; i++) {
> + if (obj->mm.placements[i]->type == type)
> + return true;
> + }
> +
> + return false;
> +}
> +
>  void i915_gem_init__objects(struct drm_i915_private *i915)
>  {
>   INIT_WORK(>mm.free_work, __i915_gem_free_work);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index d423d8cac4f2..8be4fadeee48 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -12,6 +12,7 @@
>  #include 
>  
>  #include "display/intel_frontbuffer.h"
> +#include "intel_memory_region.h"
>  #include "i915_gem_object_types.h"
>  #include "i915_gem_gtt.h"
>  #include "i915_gem_ww.h"
> @@ -607,6 +608,9 @@ bool i915_gem_object_can_migrate(struct 
> drm_i915_gem_object *obj,
>  int i915_gem_object_wait_migration(struct drm_i915_gem_object *obj,
>  unsigned int flags);
>  
> +bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
> + enum intel_memory_type type);
> +
>  #ifdef CONFIG_MMU_NOTIFIER
>  static inline bool
>  i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> index f2f850e31b8e..810a157a18f8 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
> @@ -321,8 +321,7 @@ static void *i915_gem_object_map_pfn(struct 
> drm_i915_gem_object *obj,
>   dma_addr_t addr;
>   void *vaddr;
>  
> - if (type != I915_MAP_WC)
> - return ERR_PTR(-ENODEV);
> + GEM_BUG_ON(type != I915_MAP_WC);
>  
>   if (n_pfn > ARRAY_SIZE(stack)) {
>   /* Too big for stack -- allocate temporary array instead */
> @@ -374,6 +373,25 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
> *obj,
>   }
>   GEM_BUG_ON(!i915_gem_object_has_pages(obj));
>  
> + /*
> +  * For discrete our CPU mappings needs to be consistent in order to
> +  * function correctly on !x86. When mapping things through TTM, we use
> +  * the same rules to determine the caching type.
> +  *
> +  * Internal users of lmem are already expected to get this right, so no
> +  * fudging needed there.
> +  */
> + if (i915_gem_object_placement_possible(obj, INTEL_MEMORY_LOCAL)) {
> + if (type != I915_MAP_WC && !obj->mm.n_placements) {
> + ptr = ERR_PTR(-ENODEV);
> + goto err_unpin;
> + }
> +
> +

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 7/7] dma-resv: Give the docs a do-over

2021-07-07 Thread Christian König


Am 06.07.21 um 12:12 schrieb Daniel Vetter:

Specifically document the new/clarified rules around how the shared
fences do not have any ordering requirements against the exclusive
fence.

But also document all the things a bit better, given how central
struct dma_resv to dynamic buffer management the docs have been very
inadequat.

- Lots more links to other pieces of the puzzle. Unfortunately
   ttm_buffer_object has no docs, so no links :-(

- Explain/complain a bit about dma_resv_locking_ctx(). I still don't
   like that one, but fixing the ttm call chains is going to be
   horrible. Plus we want to plug in real slowpath locking when we do
   that anyway.

- Main part of the patch is some actual docs for struct dma_resv.

Overall I think we still have a lot of bad naming in this area (e.g.
dma_resv.fence is singular, but contains the multiple shared fences),
but I think that's more indicative of how the semantics and rules are
just not great.

Another thing that's real awkard is how chaining exclusive fences
right now means direct dma_resv.exclusive_fence pointer access with an
rcu_assign_pointer. Not so great either.

Signed-off-by: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
  drivers/dma-buf/dma-resv.c |  22 ++--
  include/linux/dma-resv.h   | 104 +++--
  2 files changed, 116 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index f26c71747d43..898f8d894bbd 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -48,6 +48,8 @@
   * write operations) or N shared fences (read operations).  The RCU
   * mechanism is used to protect read access to fences from locked
   * write-side updates.
+ *
+ * See struct dma_resv for more details.
   */
  
  DEFINE_WD_CLASS(reservation_ww_class);

@@ -137,7 +139,11 @@ EXPORT_SYMBOL(dma_resv_fini);
   * @num_fences: number of fences we want to add
   *
   * Should be called before dma_resv_add_shared_fence().  Must
- * be called with obj->lock held.
+ * be called with @obj locked through dma_resv_lock().
+ *
+ * Note that the preallocated slots need to be re-reserved if @obj is unlocked
+ * at any time before callind dma_resv_add_shared_fence(). This is validate 
when
+ * CONFIG_DEBUG_MUTEXES is enabled.
   *
   * RETURNS
   * Zero for success, or -errno
@@ -234,8 +240,10 @@ EXPORT_SYMBOL(dma_resv_reset_shared_max);
   * @obj: the reservation object
   * @fence: the shared fence to add
   *
- * Add a fence to a shared slot, obj->lock must be held, and
+ * Add a fence to a shared slot, @obj must be locked with dma_resv_lock(), and
   * dma_resv_reserve_shared() has been called.
+ *
+ * See also _resv.fence for a discussion of the semantics.
   */
  void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence)
  {
@@ -280,7 +288,9 @@ EXPORT_SYMBOL(dma_resv_add_shared_fence);
   * @obj: the reservation object
   * @fence: the shared fence to add
   *
- * Add a fence to the exclusive slot.  The obj->lock must be held.
+ * Add a fence to the exclusive slot. @obj must be locked with dma_resv_lock().
+ * Note that this function replaces all fences attached to @obj, see also
+ * _resv.fence_excl for a discussion of the semantics.
   */
  void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence *fence)
  {
@@ -609,9 +619,11 @@ static inline int dma_resv_test_signaled_single(struct 
dma_fence *passed_fence)
   * fence
   *
   * Callers are not required to hold specific locks, but maybe hold
- * dma_resv_lock() already
+ * dma_resv_lock() already.
+ *
   * RETURNS
- * true if all fences signaled, else false
+ *
+ * True if all fences signaled, else false.
   */
  bool dma_resv_test_signaled(struct dma_resv *obj, bool test_all)
  {
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index e1ca2080a1ff..c77fd54d033f 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -62,16 +62,90 @@ struct dma_resv_list {
  
  /**

   * struct dma_resv - a reservation object manages fences for a buffer
- * @lock: update side lock
- * @seq: sequence count for managing RCU read-side synchronization
- * @fence_excl: the exclusive fence, if there is one currently
- * @fence: list of current shared fences
+ *
+ * There are multiple uses for this, with sometimes slightly different rules in
+ * how the fence slots are used.
+ *
+ * One use is to synchronize cross-driver access to a struct dma_buf, either 
for
+ * dynamic buffer management or just to handle implicit synchronization between
+ * different users of the buffer in userspace. See _buf.resv for a more
+ * in-depth discussion.
+ *
+ * The other major use is to manage access and locking within a driver in a
+ * buffer based memory manager. struct ttm_buffer_object is the canonical
+ * example here, since this is were reservation objects originated from. But 
use
+ * in drivers is spreading and some

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

2021-07-07 Thread Christian König




Am 02.07.21 um 19:09 schrieb Daniel Vetter:

On Thu, Jul 1, 2021 at 4:24 PM Michael J. Ruhl  wrote:

From: Thomas Hellström 

If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.

So taking the lock inside _pin_pages_unlocked() is incorrect.

Additionally, the current pinning code path is contrary to the defined
way that pinning should occur.

Remove the explicit pin/unpin from the map/umap functions and move them
to the attach/detach allowing correct locking to occur, and to match
the static dma-buf drm_prime pattern.

Add a live selftest to exercise both dynamic and non-dynamic
exports.

v2:
- Extend the selftest with a fake dynamic importer.
- Provide real pin and unpin callbacks to not abuse the interface.
v3: (ruhl)
- Remove the dynamic export support and move the pinning into the
   attach/detach path.

Reported-by: Michael J. Ruhl 
Signed-off-by: Thomas Hellström 
Signed-off-by: Michael J. Ruhl 

CI splat is because I got the locking rules wrong, I thought
->attach/detach are called under the dma_resv_lock, because when we
used the old dma_buf->lock those calls where protected by that lock
under the same critical section as adding/removing from the list. But
we changed that in

f45f57cce584 ("dma-buf: stop using the dmabuf->lock so much v2")
15fd552d186c ("dma-buf: change DMA-buf locking convention v3")

Because keeping dma_resv_lock over ->attach/detach would go boom on
all the ttm drivers, which pin/unpin the buffer in there. Iow we need
the unlocked version there, but also having this split up is a bit
awkward and might be good to patch up so that it's atomic again. Would
mean updating a bunch of drivers. Christian, any thoughts?


Yeah, we already discussed that when we switched from dma_buf->lock to 
dma_resv->lock.


In general completely agree to do this and stopping using the 
dma_buf->lock was a first step towards this, but IIRC we postponed that 
switch till later.


Regards,
Christian.

PS: I'm currently on sick leave, so response might be delayed.



Mike, for now I'd just keep using the _unlocked variants and we should be fine.
-Daniel


---
  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  46 ++--
  .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 111 +-
  2 files changed, 143 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 616c3a2f1baf..00338c8d3739 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,8 @@
  #include "i915_gem_object.h"
  #include "i915_scatterlist.h"

+I915_SELFTEST_DECLARE(static bool force_different_devices;)
+
  static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
  {
 return to_intel_bo(buf->priv);
@@ -25,15 +27,11 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
 struct scatterlist *src, *dst;
 int ret, i;

-   ret = i915_gem_object_pin_pages_unlocked(obj);
-   if (ret)
-   goto err;
-
 /* Copy sg so that we make an independent mapping */
 st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
 if (st == NULL) {
 ret = -ENOMEM;
-   goto err_unpin_pages;
+   goto err;
 }

 ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
@@ -58,8 +56,6 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
 sg_free_table(st);
  err_free:
 kfree(st);
-err_unpin_pages:
-   i915_gem_object_unpin_pages(obj);
  err:
 return ERR_PTR(ret);
  }
@@ -68,13 +64,9 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
struct sg_table *sg,
enum dma_data_direction dir)
  {
-   struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
-
 dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
 sg_free_table(sg);
 kfree(sg);
-
-   i915_gem_object_unpin_pages(obj);
  }

  static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map 
*map)
@@ -168,7 +160,32 @@ static int i915_gem_end_cpu_access(struct dma_buf 
*dma_buf, enum dma_data_direct
 return err;
  }

+/**
+ * i915_gem_dmabuf_attach - Do any extra attach work necessary
+ * @dmabuf: imported dma-buf
+ * @attach: new attach to do work on
+ *
+ */
+static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+   struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+
+   assert_object_held(obj);
+   return i915_gem_object_pin_pages(obj);
+}

[Intel-gfx] [PATCH 2/2] drivers/gpu/drm/i915/display/intel_display_power.c: Repair typo in function name

2021-07-07 Thread zhaoxiao

Fixes the following W=1 kernel build warning(s):

drivers/gpu/drm/i915/display/intel_display_power.c:2300: warning: expecting 
prototype for intel_display_power_put_async(). Prototype was for 
__intel_display_power_put_async() instead

Signed-off-by: zhaoxiao 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 4298ae684d7d..c37e14f2df90 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -2285,7 +2285,7 @@ intel_display_power_put_async_work(struct work_struct 
*work)
 }
 
 /**
- * intel_display_power_put_async - release a power domain reference 
asynchronously
+ * __intel_display_power_put_async - release a power domain reference 
asynchronously
  * @i915: i915 device instance
  * @domain: power domain to reference
  * @wakeref: wakeref acquired for the reference that is being released
-- 
2.20.1



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing

2021-07-07 Thread Nathan Chancellor


Hi Will and Robin,

On 7/6/2021 10:06 AM, Will Deacon wrote:

On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote:

On 2021-07-06 15:05, Christoph Hellwig wrote:

On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:

FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead and hacked up the alternative
(similarly untested) for comparison :)

TBH I'm still not sure which one I prefer...


Claire did implement something like your suggestion originally, but
I don't really like it as it doesn't scale for adding multiple global
pools, e.g. for the 64-bit addressable one for the various encrypted
secure guest schemes.


Ah yes, that had slipped my mind, and it's a fair point indeed. Since we're
not concerned with a minimal fix for backports anyway I'm more than happy to
focus on Will's approach. Another thing is that that looks to take us a
quiet step closer to the possibility of dynamically resizing a SWIOTLB pool,
which is something that some of the hypervisor protection schemes looking to
build on top of this series may want to explore at some point.


Ok, I'll split that nasty diff I posted up into a reviewable series and we
can take it from there.


For what it's worth, I attempted to boot Will's diff on top of Konrad's 
devel/for-linus-5.14 and it did not work; in fact, I got no output on my 
monitor period, even with earlyprintk=, and I do not think this machine 
has a serial console.


Robin's fix does work, it survived ten reboots with no issues getting to 
X and I do not see the KASAN and slub debug messages anymore but I 
understand that this is not the preferred solution it seems (although 
Konrad did want to know if it works).


I am happy to test any further patches or follow ups as needed, just 
keep me on CC.


Cheers,
Nathan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drivers/gpu/drm/i915/gt/intel_engine_cs.c: Repair typo in function name

2021-07-07 Thread zhaoxiao

Fixes the following W=1 kernel build warning(s):

drivers/gpu/drm/i915/gt/intel_engine_cs.c:882: warning: expecting prototype for 
intel_engines_init_common(). Prototype was for engine_init_common() instead
drivers/gpu/drm/i915/gt/intel_engine_cs.c:959: warning: expecting prototype for 
intel_engines_cleanup_common(). Prototype was for intel_engine_cleanup_common() 
instead

Signed-off-by: zhaoxiao 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7f03df236613..01b4dc041a72 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -868,7 +868,7 @@ create_kernel_context(struct intel_engine_cs *engine)
 }
 
 /**
- * intel_engines_init_common - initialize cengine state which might require hw 
access
+ * engine_init_common - initialize cengine state which might require hw access
  * @engine: Engine to initialize.
  *
  * Initializes @engine@ structure members shared between legacy and execlists
@@ -949,7 +949,7 @@ int intel_engines_init(struct intel_gt *gt)
 }
 
 /**
- * intel_engines_cleanup_common - cleans up the engine state created by
+ * intel_engine_cleanup_common - cleans up the engine state created by
  *the common initiailizers.
  * @engine: Engine to cleanup.
  *
-- 
2.20.1



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/etnaviv: Don't break exclusive fence ordering

On Wed, Jul 7, 2021 at 10:54 AM Lucas Stach  wrote:
>
> Hi Daniel,
>
> I'm feeling like I miss a ton of context here, so some maybe dumb
> questions/remarks below.
>
> Am Dienstag, dem 06.07.2021 um 12:12 +0200 schrieb Daniel Vetter:
> > There's only one exclusive slot, and we must not break the ordering.
> >
> > A better fix would be to us a dma_fence_chain or _array like e.g.
> > amdgpu now uses, but it probably makes sense to lift this into
> > dma-resv.c code as a proper concept, so that drivers don't have to
> > hack up their own solution each on their own. Hence go with the simple
> > fix for now.
> >
> > Another option is the fence import ioctl from Jason:
> >
> > https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
>
> Sorry, but why is the fence import ioctl a alternative to the fix
> proposed in this patch?

It's not an alternative to fixing the issue here, it's an alternative
to trying to fix this here without adding more dependencies. Depends a
bit what exactly you want to do, I just linked this for the bigger
picture.


>
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Lucas Stach 
> > Cc: Russell King 
> > Cc: Christian Gmeiner 
> > Cc: etna...@lists.freedesktop.org
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > index 92478a50a580..5c4fed2b7c6a 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > @@ -178,18 +178,20 @@ static int submit_fence_sync(struct 
> > etnaviv_gem_submit *submit)
> >   for (i = 0; i < submit->nr_bos; i++) {
> >   struct etnaviv_gem_submit_bo *bo = >bos[i];
> >   struct dma_resv *robj = bo->obj->base.resv;
> > + bool write = bo->flags & ETNA_SUBMIT_BO_WRITE;
> >
> > - if (!(bo->flags & ETNA_SUBMIT_BO_WRITE)) {
> > + if (!(write)) {
>
> No parenthesis around the write needed.
>
> >   ret = dma_resv_reserve_shared(robj, 1);
> >   if (ret)
> >   return ret;
> >   }
> >
> > - if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
> > + /* exclusive fences must be ordered */
>
> I feel like this comment isn't really helpful. It might tell you all
> you need to know if you just paged in all the context around dma_resv
> and the dependency graph, but it's not more than noise to me right now.
>
> I guess the comment should answer the question against what the
> exclusive fence we are going to add needs to be ordered and why it
> isn't safe to skip implicit sync in that case.

The full-length comment is the doc patch, which is last in the series.
Essentially the rule is that your not allowed to drop fences on the
floor (which you do if you just set a new write fence and not take any
of the existing fences as dependencies), at least for shared buffers.
But since it's easier to be consistent I think it's best if we do this
just across the board.

Like the commit message explains, there's a few ways to fix this:
- just treat it as implicit synced
- chain the fences together - that way you don't sync, but also
there's no fence that's being lost. This is what amdgpu does, and also
what the new import ioctl does.

2nd option is a lot more involved, and since all the dma-resv stuff is
a bit under discussion, I went with the most minimal thing possible.
-Daniel

>
> Regards,
> Lucas
> > + if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT && !write)
> >   continue;
> >
> >   ret = drm_sched_job_await_implicit(>sched_job, 
> > >obj->base,
> > -bo->flags & 
> > ETNA_SUBMIT_BO_WRITE);
> > +write);
> >   if (ret)
> >   return ret;
> >   }
>
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/xelpd: Fix incorrect color capability reporting

== Series Details ==

Series: drm/i915/display/xelpd: Fix incorrect color capability reporting
URL   : https://patchwork.freedesktop.org/series/92266/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10308 -> Patchwork_20542


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-snb-2520m:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-snb-2520m/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][2] ([i915#3718])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_huc_copy@huc-copy:
- fi-kbl-x1275:   NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html
- fi-skl-guc: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-skl-guc/igt@gem_huc_c...@huc-copy.html
- fi-kbl-7567u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-kbl-7567u/igt@gem_huc_c...@huc-copy.html
- fi-cfl-8109u:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u:   [PASS][7] -> [FAIL][8] ([i915#3449])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10308/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][9] -> [FAIL][10] ([i915#1372])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10308/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
- fi-skl-guc: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
- fi-kbl-7567u:   NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-kbl-7567u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-x1275:   NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-snb-2520m:   NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-snb-2520m/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-cfl-8109u:   NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-cfl-8109u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-snb-2520m:   NOTRUN -> [SKIP][16] ([fdo#109271]) +18 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-x1275:   NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-cfl-8109u:   NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#533])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20542/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-7567u:   NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#533])
   [19]:

[Intel-gfx] [PATCH i-g-t] tests/kms_addfb_basic: pass the actual fd to gem_has_lmem

2021-07-07 Thread Matthew Auld

Currently we pass the devid as if it were the fd, which doesn't work.

Signed-off-by: Matthew Auld 
Cc: Mohammed Khajapasha 
Cc: Latvala Petri 
Cc: Michael J. Ruhl 
---
 tests/kms_addfb_basic.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index 91fb6ac9..eff1d9b2 100644
--- a/tests/kms_addfb_basic.c
+++ b/tests/kms_addfb_basic.c
@@ -150,13 +150,11 @@ static void invalid_tests(int fd)
igt_describe("Check if addfb2 with a system memory gem object "
 "fails correctly if device requires local memory 
framebuffers");
igt_subtest("invalid-smem-bo-on-discrete") {
-   int devid;
uint32_t handle, stride;
uint64_t size;
 
igt_require_intel(fd);
-   devid = intel_get_drm_devid(fd);
-   igt_require(gem_has_lmem(devid));
+   igt_require(gem_has_lmem(fd));
igt_calc_fb_size(fd, f.width, f.height,
DRM_FORMAT_XRGB, 0, , );
handle = gem_create_in_memory_regions(fd, size, REGION_SMEM);
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hdcp: Dsiplay13 HDCP support over MST (rev2)

2021-07-07 Thread Gupta, Anshuman

Thanks for re-reporting.
There were non related CI-IGT failures.
Pushed to drm-intel-next.
Thanks,
Anshuman Gupta.

From: Vudum, Lakshminarayana 
Sent: Tuesday, July 6, 2021 10:12 PM
To: Gupta, Anshuman 
Cc: intel-gfx@lists.freedesktop.org
Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915/hdcp: Dsiplay13 HDCP support 
over MST (rev2)

Re-reported.

From: Gupta, Anshuman 
mailto:anshuman.gu...@intel.com>>
Sent: Tuesday, July 6, 2021 7:51 AM
To: Vudum, Lakshminarayana 
mailto:lakshminarayana.vu...@intel.com>>
Cc: intel-gfx@lists.freedesktop.org
Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915/hdcp: Dsiplay13 HDCP support 
over MST (rev2)

Hi Lakshmi
Below BAT failures are not related to HDCP at all.

igt@gem_exec_fence@basic-busy@vcs0:
fi-kbl-7567u: 
PASS
 -> 
DMESG-WARN

igt@gem_exec_parallel@engines@basic:
fi-icl-y: 
PASS
 -> 
DMESG-WARN

igt@i915_selftest@live@execlists:
fi-bdw-5557u: NOTRUN -> 
DMESG-FAIL

Could you please rise the bug for above failures and re-report the results.

Thanks,
Anshuman Gupta.
From: Patchwork 
mailto:patchw...@emeril.freedesktop.org>>
Sent: Monday, July 5, 2021 7:03 PM
To: Gupta, Anshuman mailto:anshuman.gu...@intel.com>>
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915/hdcp: Dsiplay13 HDCP support over 
MST (rev2)

Patch Details
Series:

drm/i915/hdcp: Dsiplay13 HDCP support over MST (rev2)

URL:

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

State:

failure

Details:

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

CI Bug Log - changes from CI_DRM_10305 -> Patchwork_20530
Summary

FAILURE

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

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20530, 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_20530/index.html

Possible new issues

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

IGT changes
Possible regressions

  *   igt@gem_exec_fence@basic-busy@vcs0:

 *   fi-kbl-7567u: 
PASS
 -> 
DMESG-WARN

  *   igt@gem_exec_parallel@engines@basic:

 *   fi-icl-y: 
PASS
 -> 
DMESG-WARN

  *   igt@i915_selftest@live@execlists:

 *   fi-bdw-5557u: NOTRUN -> 
DMESG-FAIL

Warnings

  *   igt@i915_pm_rpm@module-reload:

 *   fi-ivb-3770: 
SKIP
 (fdo#109271) -> 
FAIL

Suppressed

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

  *   igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:

 *   {fi-tgl-1115g4}: NOTRUN -> 
DMESG-WARN

Known issues

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

IGT changes
Issues hit

  *   igt@amdgpu/amd_basic@cs-gfx:

 *   fi-hsw-4770: NOTRUN -> 
SKIP
 (fdo#109271 / 
fdo#109315) +17 similar 
issues

  *   igt@amdgpu/amd_basic@semaphore:

 *   fi-bsw-nick: NOTRUN -> 
SKIP
 (fdo#109271) +17 similar 
issues

  *

Re: [Intel-gfx] [PATCH] drm/i915/adl_s: Fix dma_mask_size to 39 bit

2021-07-07 Thread Matthew Auld

On Wed, 7 Jul 2021 at 09:31, Tejas Upadhyay
 wrote:
>
> 46 bit addressing enables you to use 4 bits  to support some
> MKTME features, and 3 more bits for Optane support that uses
> a subset of MTKME for persistent memory.
>
> But display sticking to 39 bit addressing, thus setting dma_mask_size

What is meant by "display" here? Is this limited to the display part
of the HW? Or just in general any HW access via GGTT or ppGTT?

Also do you know if this is documented somewhere in the Bspec? If so,
adding Bspec: link would be good.

> to 39 fixes below tests :
> igt@i915_selftest@live@mman
> kms_big_fb --r linear-32bpp-rotate-0

This looks promising. From chatting with Chris it looks like this is
https://gitlab.freedesktop.org/drm/intel/-/issues/3142 ?

If so, it might be good to add a References: tag and add the following
example to the commit message:

DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [00:02.0] PASID  fault addr
7e9000 [fault reason 05] PTE Write access is not set

Also maybe highlight that the address 0x7e9000 is suspiciously
exactly 39 bits, so it seems likely that the HW just ends up masking
off those extra bits or something when doing the access, hence why we
might see strange DMAR errors?

Nice find,
Acked-by: Matthew Auld 

>
> Signed-off-by: Tejas Upadhyay 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index a7bfdd827bc8..0fea4c0c6d48 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -934,7 +934,7 @@ static const struct intel_device_info adl_s_info = {
> .display.has_psr_hw_tracking = 0,
> .platform_engine_mask =
> BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
> -   .dma_mask_size = 46,
> +   .dma_mask_size = 39,
>  };
>
>  #define XE_LPD_CURSOR_OFFSETS \
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

2021-07-07 Thread Michal Wajdeczko



On 07.07.2021 02:57, John Harrison wrote:
> On 7/3/2021 01:21, Martin Peres wrote:
>> On 02/07/2021 18:07, Michal Wajdeczko wrote:
>>> On 02.07.2021 10:09, Martin Peres wrote:
 On 02/07/2021 10:29, Pekka Paalanen wrote:
> On Thu, 1 Jul 2021 21:28:06 +0200
> Daniel Vetter  wrote:
>
>> On Thu, Jul 1, 2021 at 8:27 PM Martin Peres 
>> wrote:
>>>
>>> On 01/07/2021 11:14, Pekka Paalanen wrote:
 On Wed, 30 Jun 2021 11:58:25 -0700
 John Harrison  wrote:
> On 6/30/2021 01:22, Martin Peres wrote:
>> On 24/06/2021 10:05, Matthew Brost wrote:
>>> From: Daniele Ceraolo Spurio 
>>>
>>> Unblock GuC submission on Gen11+ platforms.
>>>
>>> Signed-off-by: Michal Wajdeczko 
>>> Signed-off-by: Daniele Ceraolo Spurio
>>> 
>>> Signed-off-by: Matthew Brost 
>>> ---
>>> drivers/gpu/drm/i915/gt/uc/intel_guc.h |  1 +
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  8 
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h |  3 +--
>>> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14
>>> +-
>>>  4 files changed, 19 insertions(+), 7 deletions(-)

 ...
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>>> index 7a69c3c027e9..61be0aa81492 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>>> @@ -34,8 +34,15 @@ static void uc_expand_default_options(struct
>>> intel_uc *uc)
>>>  return;
>>>  }
>>>  -    /* Default: enable HuC authentication only */
>>> -    i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
>>> +    /* Intermediate platforms are HuC authentication only */
>>> +    if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
>>> +    drm_dbg(>drm, "Disabling GuC only due to old
>>> platform\n");
>>
>> This comment does not seem accurate, given that DG1 is barely
>> out, and
>> ADL is not out yet. How about:
>>
>> "Disabling GuC on untested platforms"?
> Just because something is not in the shops yet does not mean it is
> new.
> Technology is always obsolete by the time it goes on sale.

 That is a very good reason to not use terminology like "new",
 "old",
 "current", "modern" etc. at all.

 End users like me definitely do not share your interpretation of
 "old".
>>>
>>> Yep, old and new is relative. In the end, what matters is the
>>> validation
>>> effort, which is why I was proposing "untested platforms".
>>>
>>> Also, remember that you are not writing these messages for Intel
>>> engineers, but instead are writing for Linux *users*.
>>
>> It's drm_dbg. Users don't read this stuff, at least not users with no
>> clue what the driver does and stuff like that.
>
> If I had a problem, I would read it, and I have no clue what anything
> of that is.

 Exactly.
> I don't see how replacing 'old' for 'untested' helps anybody to
> understand anything. Untested just implies we can't be bothered to test
> stuff before publishing it. And as previously stated, this is purely a
> political decision not a technical one. Sure, change the message to be
> 'Disabling GuC submission but enabling HuC loading via GuC on platform
> XXX' if that makes it clearer what is going on. Or just drop the message
> completely. It's simply explaining what the default option is for the
> current platform which you can also get by reading the code. However, I
> disagree that 'untested' is the correct message. Quite a lot of testing
> has been happening on TGL+ with GuC submission enabled.
> 

 This level of defense for what is clearly a bad *debug* message (at the
 very least, the grammar) makes no sense at all!

 I don't want to hear arguments like "Not my patch" from a developer
 literally sending the patch to the ML and who added his SoB to the
 patch, playing with words, or minimizing the problem of having such a
 message.
>>>
>>> Agree that 'not my patch' is never a good excuse, but equally we can't
>>> blame original patch author as patch was updated few times since then.
>>
>> I never wanted to blame the author here, I was only speaking about the
>> handling of feedback on the patch.
>>
>>>
>>> Maybe to avoid confusions and simplify reviews, we could split this
>>> patch into two smaller: first one that really unblocks GuC submission on
>>> all Gen11+ (see __guc_submission_supported) and second one that updates
>>> defaults for Gen12+ (see uc_expand_default_options), as original patch
>>> (from ~2019) evolved more than what title/commit message says.
>>
>> Both work for me, as long as

Re: [Intel-gfx] [PATCH 0/2] Update to new HuC for TGL+ and enable GuC/HuC on ADL-P

2021-07-07 Thread Michal Wajdeczko

Hi John,

On 26.06.2021 02:45, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> There is a new HuC version available for TGL and compatible platforms,
> so switch to using it. Also, there is now a GuC and HuC for ADL-P, so
> use those too.

I recall discussion about splitting UC_FW meta macro into two: one for
GUC firmwares and other for HUC firmwares - what happen to this idea?

Maybe we can do it in this series as a first step ? then changing just
HuC version will be limited to HUC meta macro only.

Michal

> 
> Signed-off-by: John Harrison 
> 
> 
> John Harrison (2):
>   drm/i915/huc: Update TGL and friends to HuC 7.9.3
>   drm/i915/adlp: Add ADL-P GuC/HuC firmware files
> 
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/adl_s: Fix dma_mask_size to 39 bit

== Series Details ==

Series: drm/i915/adl_s: Fix dma_mask_size to 39 bit
URL   : https://patchwork.freedesktop.org/series/92262/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10308 -> Patchwork_20541


Summary
---

  **FAILURE**

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

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-snb-2520m:   NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-snb-2520m/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][2] ([i915#3718])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

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

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

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-snb-2520m:   NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-snb-2520m/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-cfl-8109u:   NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-cfl-8109u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-snb-2520m:   NOTRUN -> [SKIP][8] ([fdo#109271]) +18 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-snb-2520m/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-x1275:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-cfl-8109u:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

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

  * igt@kms_psr@primary_mmap_gtt:
- fi-cfl-8109u:   NOTRUN -> [SKIP][12] ([fdo#109271]) +6 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-cfl-8109u/igt@kms_psr@primary_mmap_gtt.html

  * igt@kms_psr@primary_page_flip:
- fi-kbl-x1275:   NOTRUN -> [SKIP][13] ([fdo#109271]) +8 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-kbl-x1275/igt@kms_psr@primary_page_flip.html

  * igt@runner@aborted:
- fi-kbl-x1275:   NOTRUN -> [FAIL][14] ([i915#2722] / [i915#3363])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-kbl-x1275/igt@run...@aborted.html
- fi-cfl-8109u:   NOTRUN -> [FAIL][15] ([i915#2722] / [i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-cfl-8109u/igt@run...@aborted.html

  * igt@vgem_basic@unload:
- fi-cfl-8109u:   NOTRUN -> [INCOMPLETE][16] ([i915#3744])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-cfl-8109u/igt@vgem_ba...@unload.html
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][17] ([i915#3744])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-bdw-5557u/igt@vgem_ba...@unload.html
- fi-kbl-x1275:   NOTRUN -> [INCOMPLETE][18] ([i915#3744])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20541/fi-kbl-x1275/igt@vgem_ba...@unload.html
- fi-snb-2520m:   NOTRUN -> [INCOMPLETE][19]

[Intel-gfx] [PATCH] drm/i915/display/xelpd: Fix incorrect color capability reporting

2021-07-07 Thread Uma Shankar

On XELPD platforms, color management support is not yet enabled.
Fix wrongly reporting the same through platform info, which was
resulting in incorrect initialization and usage.

Cc: Swati Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a7bfdd827bc8..8ff1990528d1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -947,7 +947,7 @@ static const struct intel_device_info adl_s_info = {
 
 #define XE_LPD_FEATURES \
.abox_mask = GENMASK(1, 0), 
\
-   .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 },  
\
+   .color = { .degamma_lut_size = 0, .gamma_lut_size = 0 },
\
.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |  
\
BIT(TRANSCODER_C) | BIT(TRANSCODER_D),  
\
.dbuf.size = 4096,  
\
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 7/7] dma-resv: Give the docs a do-over

On Wed, Jul 7, 2021 at 10:06 AM Christian König
 wrote:
>
> Am 06.07.21 um 12:12 schrieb Daniel Vetter:
> > Specifically document the new/clarified rules around how the shared
> > fences do not have any ordering requirements against the exclusive
> > fence.
> >
> > But also document all the things a bit better, given how central
> > struct dma_resv to dynamic buffer management the docs have been very
> > inadequat.
> >
> > - Lots more links to other pieces of the puzzle. Unfortunately
> >ttm_buffer_object has no docs, so no links :-(
> >
> > - Explain/complain a bit about dma_resv_locking_ctx(). I still don't
> >like that one, but fixing the ttm call chains is going to be
> >horrible. Plus we want to plug in real slowpath locking when we do
> >that anyway.
> >
> > - Main part of the patch is some actual docs for struct dma_resv.
> >
> > Overall I think we still have a lot of bad naming in this area (e.g.
> > dma_resv.fence is singular, but contains the multiple shared fences),
> > but I think that's more indicative of how the semantics and rules are
> > just not great.
> >
> > Another thing that's real awkard is how chaining exclusive fences
> > right now means direct dma_resv.exclusive_fence pointer access with an
> > rcu_assign_pointer. Not so great either.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Sumit Semwal 
> > Cc: "Christian König" 
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > ---
> >   drivers/dma-buf/dma-resv.c |  22 ++--
> >   include/linux/dma-resv.h   | 104 +++--
> >   2 files changed, 116 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index f26c71747d43..898f8d894bbd 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -48,6 +48,8 @@
> >* write operations) or N shared fences (read operations).  The RCU
> >* mechanism is used to protect read access to fences from locked
> >* write-side updates.
> > + *
> > + * See struct dma_resv for more details.
> >*/
> >
> >   DEFINE_WD_CLASS(reservation_ww_class);
> > @@ -137,7 +139,11 @@ EXPORT_SYMBOL(dma_resv_fini);
> >* @num_fences: number of fences we want to add
> >*
> >* Should be called before dma_resv_add_shared_fence().  Must
> > - * be called with obj->lock held.
> > + * be called with @obj locked through dma_resv_lock().
> > + *
> > + * Note that the preallocated slots need to be re-reserved if @obj is 
> > unlocked
> > + * at any time before callind dma_resv_add_shared_fence(). This is 
> > validate when
> > + * CONFIG_DEBUG_MUTEXES is enabled.
> >*
> >* RETURNS
> >* Zero for success, or -errno
> > @@ -234,8 +240,10 @@ EXPORT_SYMBOL(dma_resv_reset_shared_max);
> >* @obj: the reservation object
> >* @fence: the shared fence to add
> >*
> > - * Add a fence to a shared slot, obj->lock must be held, and
> > + * Add a fence to a shared slot, @obj must be locked with dma_resv_lock(), 
> > and
> >* dma_resv_reserve_shared() has been called.
> > + *
> > + * See also _resv.fence for a discussion of the semantics.
> >*/
> >   void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence 
> > *fence)
> >   {
> > @@ -280,7 +288,9 @@ EXPORT_SYMBOL(dma_resv_add_shared_fence);
> >* @obj: the reservation object
> >* @fence: the shared fence to add
> >*
> > - * Add a fence to the exclusive slot.  The obj->lock must be held.
> > + * Add a fence to the exclusive slot. @obj must be locked with 
> > dma_resv_lock().
> > + * Note that this function replaces all fences attached to @obj, see also
> > + * _resv.fence_excl for a discussion of the semantics.
> >*/
> >   void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence 
> > *fence)
> >   {
> > @@ -609,9 +619,11 @@ static inline int dma_resv_test_signaled_single(struct 
> > dma_fence *passed_fence)
> >* fence
> >*
> >* Callers are not required to hold specific locks, but maybe hold
> > - * dma_resv_lock() already
> > + * dma_resv_lock() already.
> > + *
> >* RETURNS
> > - * true if all fences signaled, else false
> > + *
> > + * True if all fences signaled, else false.
> >*/
> >   bool dma_resv_test_signaled(struct dma_resv *obj, bool test_all)
> >   {
> > diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> > index e1ca2080a1ff..c77fd54d033f 100644
> > --- a/include/linux/dma-resv.h
> > +++ b/include/linux/dma-resv.h
> > @@ -62,16 +62,90 @@ struct dma_resv_list {
> >
> >   /**
> >* struct dma_resv - a reservation object manages fences for a buffer
> > - * @lock: update side lock
> > - * @seq: sequence count for managing RCU read-side synchronization
> > - * @fence_excl: the exclusive fence, if there is one currently
> > - * @fence: list of current shared fences
> > + *
> > + * There are multiple uses for this, with sometimes slightly different 
> > rules in
> > + * how the fence slots are used.
>

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dmc: Use RUNTIME_INFO->step for DMC

On Wed, 07 Jul 2021, Jani Nikula  wrote:
> On Tue, 06 Jul 2021, Anusha Srivatsa  wrote:
>> Instead of adding new table for every new platform, lets ues
>> the stepping info from RUNTIME_INFO(dev_priv)->step
>> This patch uses RUNTIME_INFO->step only for recent
>> platforms.
>>
>> Patches that follow this will address this change for
>> remaining platforms + missing platforms.
>>
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  drivers/gpu/drm/i915/display/intel_dmc.c | 61 +---
>>  1 file changed, 54 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
>> b/drivers/gpu/drm/i915/display/intel_dmc.c
>> index f8789d4543bf..a38720f25910 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>> @@ -266,10 +266,12 @@ static const struct stepping_info icl_stepping_info[] 
>> = {
>>  };
>>  
>>  static const struct stepping_info no_stepping_info = { '*', '*' };
>> +struct stepping_info *display_step;
>
> We can't have driver specific mutable data for this. Almost everything
> has to be either device specific or const. The above would be shared
> between all devices.

I think the solution to your problem is two-fold.

First, I think you should add a *generic* function in intel_step.c to
get the chars or a string for an enum intel_step. Maybe a string,
because it'll also be useful for logging?

const char *intel_step_name(enum intel_step step)
{
switch (step) {
case STEP_A0:
return "A0";
case STEP_B0;
/* etc ... */
default:
return "??";
}
}

Second, I think you should modify intel_get_stepping_info() to let you
pass in the struct stepping_info pointer to fill in. Then you can have a
local struct stepping_info si variable in parse_dmc_fw(). We don't need
to store the data anywhere, it's only used once.

static void intel_get_stepping_info(struct drm_i915_private *dev_priv,
   struct stepping_info *si)

There you'd do something like:

const char *step_name = intel_step_name(step);

si->stepping = step_name[0];
si->stepping = step_name[1];

And potentially handle the ?? case separately. Something along those
lines.

BR,
Jani.


>
> BR,
> Jani.
>
>>  
>>  static const struct stepping_info *
>>  intel_get_stepping_info(struct drm_i915_private *dev_priv)
>>  {
>> +struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
>>  const struct stepping_info *si;
>>  unsigned int size;
>>  
>> @@ -282,15 +284,60 @@ intel_get_stepping_info(struct drm_i915_private 
>> *dev_priv)
>>  } else if (IS_BROXTON(dev_priv)) {
>>  size = ARRAY_SIZE(bxt_stepping_info);
>>  si = bxt_stepping_info;
>> -} else {
>> -size = 0;
>> -si = NULL;
>>  }
>>  
>> -if (INTEL_REVID(dev_priv) < size)
>> -return si + INTEL_REVID(dev_priv);
>> -
>> -return _stepping_info;
>> +if (IS_ICELAKE(dev_priv) || IS_SKYLAKE(dev_priv) || 
>> IS_BROXTON(dev_priv))
>> +return INTEL_REVID(dev_priv) < size ? si + 
>> INTEL_REVID(dev_priv) : _stepping_info;
>> +
>> +else {
>> +switch (step.display_step) {
>> +case STEP_A0:
>> +display_step->stepping = 'A';
>> +display_step->substepping = '0';
>> +break;
>> +case STEP_A2:
>> +display_step->stepping = 'A';
>> +display_step->substepping = '2';
>> +break;
>> +case STEP_B0:
>> +display_step->stepping = 'B';
>> +display_step->substepping = '0';
>> +break;
>> +case STEP_B1:
>> +display_step->stepping = 'B';
>> +display_step->substepping = '1';
>> +break;
>> +case STEP_C0:
>> +display_step->stepping = 'C';
>> +display_step->substepping = '0';
>> +break;
>> +case STEP_D0:
>> +display_step->stepping = 'D';
>> +display_step->substepping = '0';
>> +break;
>> +case STEP_D1:
>> +display_step->stepping = 'D';
>> +display_step->substepping = '1';
>> +break;
>> +case STEP_E0:
>> +display_step->stepping = 'E';
>> +display_step->substepping = '0';
>> +break;
>> +case STEP_F0:
>> +display_step->stepping = 'F';
>> +display_step->substepping = '0';
>> +break;
>> +case STEP_G0:
>> +display_step->stepping = 'G';
>> +display_step->substepping = '0';
>> +break;
>> +default:
>> +

Re: [Intel-gfx] [PATCH 3/7] drm/etnaviv: Don't break exclusive fence ordering

2021-07-07 Thread Lucas Stach

Hi Daniel,

I'm feeling like I miss a ton of context here, so some maybe dumb
questions/remarks below.

Am Dienstag, dem 06.07.2021 um 12:12 +0200 schrieb Daniel Vetter:
> There's only one exclusive slot, and we must not break the ordering.
> 
> A better fix would be to us a dma_fence_chain or _array like e.g.
> amdgpu now uses, but it probably makes sense to lift this into
> dma-resv.c code as a proper concept, so that drivers don't have to
> hack up their own solution each on their own. Hence go with the simple
> fix for now.
> 
> Another option is the fence import ioctl from Jason:
> 
> https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/

Sorry, but why is the fence import ioctl a alternative to the fix
proposed in this patch?

> 
> Signed-off-by: Daniel Vetter 
> Cc: Lucas Stach 
> Cc: Russell King 
> Cc: Christian Gmeiner 
> Cc: etna...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index 92478a50a580..5c4fed2b7c6a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -178,18 +178,20 @@ static int submit_fence_sync(struct etnaviv_gem_submit 
> *submit)
>   for (i = 0; i < submit->nr_bos; i++) {
>   struct etnaviv_gem_submit_bo *bo = >bos[i];
>   struct dma_resv *robj = bo->obj->base.resv;
> + bool write = bo->flags & ETNA_SUBMIT_BO_WRITE;
>  
> - if (!(bo->flags & ETNA_SUBMIT_BO_WRITE)) {
> + if (!(write)) {

No parenthesis around the write needed.

>   ret = dma_resv_reserve_shared(robj, 1);
>   if (ret)
>   return ret;
>   }
>  
> - if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
> + /* exclusive fences must be ordered */

I feel like this comment isn't really helpful. It might tell you all
you need to know if you just paged in all the context around dma_resv
and the dependency graph, but it's not more than noise to me right now.

I guess the comment should answer the question against what the
exclusive fence we are going to add needs to be ordered and why it
isn't safe to skip implicit sync in that case.

Regards,
Lucas 
> + if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT && !write)
>   continue;
>  
>   ret = drm_sched_job_await_implicit(>sched_job, 
> >obj->base,
> -bo->flags & 
> ETNA_SUBMIT_BO_WRITE);
> +write);
>   if (ret)
>   return ret;
>   }


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/53] drm/i915: Add "release id" version

On Tue, 06 Jul 2021, Lucas De Marchi  wrote:
> On Mon, Jul 05, 2021 at 02:52:31PM +0300, Jani Nikula wrote:
>>On Fri, 02 Jul 2021, Tvrtko Ursulin  wrote:
>>> On 01/07/2021 21:23, Matt Roper wrote:
 From: Lucas De Marchi 

 Besides the arch version returned by GRAPHICS_VER(), new platforms
 contain a "release id" to make clear the difference from one platform to
 another. Although for the first ones we may use them as if they were a
>>>
>>> What does "first ones" refer to here?
>>>
 major/minor version, that is not true for all platforms: we may have a
 `release_id == n` that is closer to `n - 2` than to `n - 1`.
>>>
>>> Hm this is a bit confusing. Is the sentence simply trying to say that,
>>> as the release id number is growing, hw capabilities are not simply
>>> accumulating but can be removed as well? Otherwise I am not sure how the
>>> user of these macros is supposed to act on this sentence.
>>>
 However the release id number is not defined by hardware until we start
 using the GMD_ID register. For the platforms before that register is
 useful we will set the values in software and we can set them as we
 please. So the plan is to set them so we can group different features
 under a single GRAPHICS_VER_FULL() check.

 After GMD_ID is used, the usefulness of a "full version check" will be
 greatly reduced and will be mostly used for deciding workarounds and a
 few code paths. So it makes sense to keep it as a separate field from
 graphics_ver.

 Also, currently there is not much use for the release id in media and
 display, so keep them out.

 This is a mix of 2 independent changes: one by me and the other by Matt
 Roper.

 Cc: Matt Roper 
 Signed-off-by: Lucas De Marchi 
 Signed-off-by: Matt Roper 
 ---
   drivers/gpu/drm/i915/i915_drv.h  | 6 ++
   drivers/gpu/drm/i915/intel_device_info.c | 2 ++
   drivers/gpu/drm/i915/intel_device_info.h | 2 ++
   3 files changed, 10 insertions(+)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index 6dff4ca01241..9639800485b9 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1258,11 +1258,17 @@ static inline struct drm_i915_private 
 *pdev_to_i915(struct pci_dev *pdev)
*/
   #define IS_GEN(dev_priv, n)  (GRAPHICS_VER(dev_priv) == (n))

 +#define IP_VER(ver, release)  ((ver) << 8 | (release))
 +
   #define GRAPHICS_VER(i915)   (INTEL_INFO(i915)->graphics_ver)
 +#define GRAPHICS_VER_FULL(i915)   
 IP_VER(INTEL_INFO(i915)->graphics_ver, \
 + 
 INTEL_INFO(i915)->graphics_ver_release)
   #define IS_GRAPHICS_VER(i915, from, until) \
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))

   #define MEDIA_VER(i915)  (INTEL_INFO(i915)->media_ver)
 +#define MEDIA_VER_FULL(i915)  
 IP_VER(INTEL_INFO(i915)->media_ver, \
 + 
 INTEL_INFO(i915)->media_ver_release)
   #define IS_MEDIA_VER(i915, from, until) \
(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))

 diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
 b/drivers/gpu/drm/i915/intel_device_info.c
 index 7eaa92fee421..e8ad14f002c1 100644
 --- a/drivers/gpu/drm/i915/intel_device_info.c
 +++ b/drivers/gpu/drm/i915/intel_device_info.c
 @@ -97,7 +97,9 @@ void intel_device_info_print_static(const struct 
 intel_device_info *info,
struct drm_printer *p)
   {
drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);
 +  drm_printf(p, "graphics_ver_release: %u\n", info->graphics_ver_release);
>>>
>>> I get the VER and VER_FULL in the macros but could 'ver' and
>>> 'ver_release' here and in the code simply be renamed to 'ver'/'version'
>>> and 'release'? Maybe it is just me but don't think I encountered the
>>> term "version release" before.
>>
>>Just bikeshedding here, but I thought of:
>>
>>  if (info->grapics_ver_release)
>>  drm_printf(p, "graphics_ver: %u.%u\n", info->graphics_ver, 
>> info->graphics_ver_release);
>>  else
>>  drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);
>
> humn... a suggestion that I got internally a few week ago and I forgot
> to update this was that this doesn't need to be abbreviated in debugfs
> and could very well be:
>
>   drm_printf(p, "graphics version: %u\n", info->graphics_ver);
>   drm_printf(p, "graphics release: %u\n", info->graphics_ver_release);
>>
>>Also, I thought "x_ver" and "x_ver_release" sounds a bit odd, perhaps
>>having "x_ver" and "x_rel" is more natural?
>
> Not sure what direction to go now though. Maybe trying to put all
> suggestions together:
>
>

[Intel-gfx] [PATCH] drm/i915/adl_s: Fix dma_mask_size to 39 bit

2021-07-07 Thread Tejas Upadhyay

46 bit addressing enables you to use 4 bits  to support some
MKTME features, and 3 more bits for Optane support that uses
a subset of MTKME for persistent memory.

But display sticking to 39 bit addressing, thus setting dma_mask_size
to 39 fixes below tests :
igt@i915_selftest@live@mman
kms_big_fb --r linear-32bpp-rotate-0

Signed-off-by: Tejas Upadhyay 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a7bfdd827bc8..0fea4c0c6d48 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -934,7 +934,7 @@ static const struct intel_device_info adl_s_info = {
.display.has_psr_hw_tracking = 0,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
-   .dma_mask_size = 46,
+   .dma_mask_size = 39,
 };
 
 #define XE_LPD_CURSOR_OFFSETS \
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dmc: Use RUNTIME_INFO->step for DMC

On Tue, 06 Jul 2021, Anusha Srivatsa  wrote:
> Instead of adding new table for every new platform, lets ues
> the stepping info from RUNTIME_INFO(dev_priv)->step
> This patch uses RUNTIME_INFO->step only for recent
> platforms.
>
> Patches that follow this will address this change for
> remaining platforms + missing platforms.
>
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/display/intel_dmc.c | 61 +---
>  1 file changed, 54 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index f8789d4543bf..a38720f25910 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -266,10 +266,12 @@ static const struct stepping_info icl_stepping_info[] = 
> {
>  };
>  
>  static const struct stepping_info no_stepping_info = { '*', '*' };
> +struct stepping_info *display_step;

We can't have driver specific mutable data for this. Almost everything
has to be either device specific or const. The above would be shared
between all devices.

BR,
Jani.

>  
>  static const struct stepping_info *
>  intel_get_stepping_info(struct drm_i915_private *dev_priv)
>  {
> + struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
>   const struct stepping_info *si;
>   unsigned int size;
>  
> @@ -282,15 +284,60 @@ intel_get_stepping_info(struct drm_i915_private 
> *dev_priv)
>   } else if (IS_BROXTON(dev_priv)) {
>   size = ARRAY_SIZE(bxt_stepping_info);
>   si = bxt_stepping_info;
> - } else {
> - size = 0;
> - si = NULL;
>   }
>  
> - if (INTEL_REVID(dev_priv) < size)
> - return si + INTEL_REVID(dev_priv);
> -
> - return _stepping_info;
> + if (IS_ICELAKE(dev_priv) || IS_SKYLAKE(dev_priv) || 
> IS_BROXTON(dev_priv))
> + return INTEL_REVID(dev_priv) < size ? si + 
> INTEL_REVID(dev_priv) : _stepping_info;
> +
> + else {
> + switch (step.display_step) {
> + case STEP_A0:
> + display_step->stepping = 'A';
> + display_step->substepping = '0';
> + break;
> + case STEP_A2:
> + display_step->stepping = 'A';
> + display_step->substepping = '2';
> + break;
> + case STEP_B0:
> + display_step->stepping = 'B';
> + display_step->substepping = '0';
> + break;
> + case STEP_B1:
> + display_step->stepping = 'B';
> + display_step->substepping = '1';
> + break;
> + case STEP_C0:
> + display_step->stepping = 'C';
> + display_step->substepping = '0';
> + break;
> + case STEP_D0:
> + display_step->stepping = 'D';
> + display_step->substepping = '0';
> + break;
> + case STEP_D1:
> + display_step->stepping = 'D';
> + display_step->substepping = '1';
> + break;
> + case STEP_E0:
> + display_step->stepping = 'E';
> + display_step->substepping = '0';
> + break;
> + case STEP_F0:
> + display_step->stepping = 'F';
> + display_step->substepping = '0';
> + break;
> + case STEP_G0:
> + display_step->stepping = 'G';
> + display_step->substepping = '0';
> + break;
> + default:
> + display_step->stepping = '*';
> + display_step->substepping = '*';
> + break;
> + }
> + }
> + return display_step;
>  }
>  
>  static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/8] drm/i915/step: s/_revid_tbl/_revids

On Tue, 06 Jul 2021, Anusha Srivatsa  wrote:
> Simplify the stepping info array name.
>
> Cc: Jani Nikula 
> Signed-off-by: Anusha Srivatsa 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/intel_step.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_step.c 
> b/drivers/gpu/drm/i915/intel_step.c
> index ba9479a67521..93ccd42f2514 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -26,7 +26,7 @@ static const struct intel_step_info kbl_revids[] = {
>   [7] = { .gt_step = STEP_G0, .display_step = STEP_C0 },
>  };
>  
> -static const struct intel_step_info tgl_uy_revid_step_tbl[] = {
> +static const struct intel_step_info tgl_uy_revids[] = {
>   [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
>   [1] = { .gt_step = STEP_B0, .display_step = STEP_C0 },
>   [2] = { .gt_step = STEP_B1, .display_step = STEP_C0 },
> @@ -34,12 +34,12 @@ static const struct intel_step_info 
> tgl_uy_revid_step_tbl[] = {
>  };
>  
>  /* Same GT stepping between tgl_uy_revids and tgl_revids don't mean the same 
> HW */
> -static const struct intel_step_info tgl_revid_step_tbl[] = {
> +static const struct intel_step_info tgl_revids[] = {
>   [0] = { .gt_step = STEP_A0, .display_step = STEP_B0 },
>   [1] = { .gt_step = STEP_B0, .display_step = STEP_D0 },
>  };
>  
> -static const struct intel_step_info adls_revid_step_tbl[] = {
> +static const struct intel_step_info adls_revids[] = {
>   [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
>   [0x1] = { .gt_step = STEP_A0, .display_step = STEP_A2 },
>   [0x4] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
> @@ -47,7 +47,7 @@ static const struct intel_step_info adls_revid_step_tbl[] = 
> {
>   [0xC] = { .gt_step = STEP_D0, .display_step = STEP_C0 },
>  };
>  
> -static const struct intel_step_info adlp_revid_step_tbl[] = {
> +static const struct intel_step_info adlp_revids[] = {
>   [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
>   [0x4] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
>   [0x8] = { .gt_step = STEP_C0, .display_step = STEP_C0 },
> @@ -62,17 +62,17 @@ void intel_step_init(struct drm_i915_private *i915)
>   struct intel_step_info step = {};
>  
>   if (IS_ALDERLAKE_P(i915)) {
> - revids = adlp_revid_step_tbl;
> - size = ARRAY_SIZE(adlp_revid_step_tbl);
> + revids = adlp_revids;
> + size = ARRAY_SIZE(adlp_revids);
>   } else if (IS_ALDERLAKE_S(i915)) {
> - revids = adls_revid_step_tbl;
> - size = ARRAY_SIZE(adls_revid_step_tbl);
> + revids = adls_revids;
> + size = ARRAY_SIZE(adls_revids);
>   } else if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
> - revids = tgl_uy_revid_step_tbl;
> - size = ARRAY_SIZE(tgl_uy_revid_step_tbl);
> + revids = tgl_uy_revids;
> + size = ARRAY_SIZE(tgl_uy_revids);
>   } else if (IS_TIGERLAKE(i915)) {
> - revids = tgl_revid_step_tbl;
> - size = ARRAY_SIZE(tgl_revid_step_tbl);
> + revids = tgl_revids;
> + size = ARRAY_SIZE(tgl_revids);
>   } else if (IS_KABYLAKE(i915)) {
>   revids = kbl_revids;
>   size = ARRAY_SIZE(kbl_revids);

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

2021-07-07 Thread Pekka Paalanen

On Tue, 6 Jul 2021 17:57:35 -0700
John Harrison  wrote:

> On 7/3/2021 01:21, Martin Peres wrote:
> > On 02/07/2021 18:07, Michal Wajdeczko wrote:  
> >> On 02.07.2021 10:09, Martin Peres wrote:  
> >>> On 02/07/2021 10:29, Pekka Paalanen wrote:  
>  On Thu, 1 Jul 2021 21:28:06 +0200
>  Daniel Vetter  wrote:
>   
> > On Thu, Jul 1, 2021 at 8:27 PM Martin Peres 
> > wrote:  
> >>
> >> On 01/07/2021 11:14, Pekka Paalanen wrote:  
> >>> On Wed, 30 Jun 2021 11:58:25 -0700
> >>> John Harrison  wrote:  
>  On 6/30/2021 01:22, Martin Peres wrote:  
> > On 24/06/2021 10:05, Matthew Brost wrote:  
> >> From: Daniele Ceraolo Spurio 
> >>
> >> Unblock GuC submission on Gen11+ platforms.
> >>
> >> Signed-off-by: Michal Wajdeczko 
> >> Signed-off-by: Daniele Ceraolo Spurio
> >> 
> >> Signed-off-by: Matthew Brost 
> >> ---
> >> drivers/gpu/drm/i915/gt/uc/intel_guc.h |  1 +
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  8 
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h |  3 +--
> >> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14
> >> +-
> >>  4 files changed, 19 insertions(+), 7 deletions(-)  
> >>>
> >>> ...  
> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> index 7a69c3c027e9..61be0aa81492 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> @@ -34,8 +34,15 @@ static void uc_expand_default_options(struct
> >> intel_uc *uc)
> >>  return;
> >>  }
> >>  -    /* Default: enable HuC authentication only */
> >> -    i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> >> +    /* Intermediate platforms are HuC authentication only */
> >> +    if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
> >> +    drm_dbg(>drm, "Disabling GuC only due to old
> >> platform\n");  
> >
> > This comment does not seem accurate, given that DG1 is barely
> > out, and
> > ADL is not out yet. How about:
> >
> > "Disabling GuC on untested platforms"?  
>  Just because something is not in the shops yet does not mean it is
>  new.
>  Technology is always obsolete by the time it goes on sale.  
> >>>
> >>> That is a very good reason to not use terminology like "new", 
> >>> "old",
> >>> "current", "modern" etc. at all.
> >>>
> >>> End users like me definitely do not share your interpretation of
> >>> "old".  
> >>
> >> Yep, old and new is relative. In the end, what matters is the
> >> validation
> >> effort, which is why I was proposing "untested platforms".
> >>
> >> Also, remember that you are not writing these messages for Intel
> >> engineers, but instead are writing for Linux *users*.  
> >
> > It's drm_dbg. Users don't read this stuff, at least not users with no
> > clue what the driver does and stuff like that.  
> 
>  If I had a problem, I would read it, and I have no clue what anything
>  of that is.  
> >>>
> >>> Exactly.  
> I don't see how replacing 'old' for 'untested' helps anybody to 
> understand anything. Untested just implies we can't be bothered to test 
> stuff before publishing it. And as previously stated, this is purely a 
> political decision not a technical one. Sure, change the message to be 
> 'Disabling GuC submission but enabling HuC loading via GuC on platform 
> XXX' if that makes it clearer what is going on. Or just drop the message 
> completely. It's simply explaining what the default option is for the 
> current platform which you can also get by reading the code. However, I 
> disagree that 'untested' is the correct message. Quite a lot of testing 
> has been happening on TGL+ with GuC submission enabled.

Hi,

it seems to me that "untested" was just a wrong guess, nothing more. It
was presented with "how about?", not as an exact demand.

You don't have to attack that word, just use another phrasing that is
both correct and not misleading to the majority of tech savvy people.


Thanks,
pq


pgpbR2dyrXXpD.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/53] drm/i915/xehp: Extra media engines - Part 2 (interrupts)

2021-07-07 Thread Tvrtko Ursulin



On 06/07/2021 22:15, Lucas De Marchi wrote:

On Fri, Jul 02, 2021 at 01:42:59PM +0100, Tvrtko Ursulin wrote:


On 01/07/2021 21:23, Matt Roper wrote:

From: John Harrison 

Xe_HP can have a lot of extra media engines. This patch adds the
interrupt handler support for them.

Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: John Harrison 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 -
 drivers/gpu/drm/i915/i915_reg.h    |  3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

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

index c13462274fe8..b2de83be4d97 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -184,7 +184,13 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
 intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK,    ~0);
 intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK,    ~0);
 intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK,    ~0);
+    if (HAS_ENGINE(gt, VCS4) || HAS_ENGINE(gt, VCS5))
+    intel_uncore_write(uncore, GEN12_VCS4_VCS5_INTR_MASK,   ~0);
+    if (HAS_ENGINE(gt, VCS6) || HAS_ENGINE(gt, VCS7))
+    intel_uncore_write(uncore, GEN12_VCS6_VCS7_INTR_MASK,   ~0);
 intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK,    ~0);
+    if (HAS_ENGINE(gt, VECS2) || HAS_ENGINE(gt, VECS3))
+    intel_uncore_write(uncore, GEN12_VECS2_VECS3_INTR_MASK, ~0);
 intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
 intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK,  ~0);
@@ -218,8 +224,13 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
 intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK, ~smask);
 intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK, ~dmask);
 intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK, ~dmask);
+    if (HAS_ENGINE(gt, VCS4) || HAS_ENGINE(gt, VCS5))
+    intel_uncore_write(uncore, GEN12_VCS4_VCS5_INTR_MASK, ~dmask);
+    if (HAS_ENGINE(gt, VCS6) || HAS_ENGINE(gt, VCS7))
+    intel_uncore_write(uncore, GEN12_VCS6_VCS7_INTR_MASK, ~dmask);
 intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK, ~dmask);


Poor 0-1 sandwiched between 4-7 and 2-3. ;) With hopefully order 
restored:


not sure I understand this, order looks correct to me. It handles all
(possible) VCS engines, and later VECS


Oops my bad, my eyes confused VCS and VECS blocks.

Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/53] drm/i915: Fork DG1 interrupt handler