[Intel-gfx] [PATCH v2 10/14] drm/i915/tgl: Fix the Wa number of a fix
The Wa number for this fix is Wa_1607087056 the BSpec bug id is 1607087056, just updating to match BSpec. BSpec: 52890 Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 92cc412cd93c..e7ca0eab2700 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -936,7 +936,7 @@ tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list *wal) SUBSLICE_UNIT_LEVEL_CLKGATE2, CPSSUNIT_CLKGATE_DIS); - /* Wa_1409180338:tgl */ + /* Wa_1607087056:tgl also know as BUG:1409180338 */ if (IS_TGL_GT_REVID(i915, TGL_GT_REVID_A0, TGL_GT_REVID_A0)) wa_write_or(wal, SLICE_UNIT_LEVEL_CLKGATE, -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/14] drm/i915/tgl: Add note about Wa_1607063988
This issue workaround in Wa_1607063988 has the same fix as Wa_1607138336, so just adding a note in the code. Reviewed-by: Matt Roper Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 143ff3daab0d..92cc412cd93c 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1338,7 +1338,10 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal) GEN9_CS_DEBUG_MODE1, FF_DOP_CLOCK_GATE_DISABLE); - /* Wa_1607138336:tgl */ + /* +* Wa_1607138336:tgl +* Wa_1607063988:tgl +*/ wa_write_or(wal, GEN9_CTX_PREEMPT_REG, GEN12_DISABLE_POSH_BUSY_FF_DOP_CG); -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/14] drm/i915/tgl: Extend Wa_1606931601 for all steppings
From: Anusha Srivatsa
According to BSpec. Wa_1606931601 applies for all TGL steppings.
This patch moves the WA implementation out of A0 only block of
rcs_engine_wa_init().
The WA is has also been referred to by an alternate name
Wa_1607090982.
Bspec: 46045, 52890
Fixes: 3873fd1a43c7 ("drm/i915: Use engine wa list for Wa_1607090982")
Cc: Mika Kuoppala
Signed-off-by: Anusha Srivatsa
Signed-off-by: José Roberto de Souza
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 1d1aa3967add..bc0af522542b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1364,11 +1364,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
GEN7_FF_THREAD_MODE,
GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
- /* Wa_1606931601:tgl */
- wa_masked_en(wal,
-GEN7_ROW_CHICKEN2,
-GEN12_DISABLE_EARLY_READ);
-
/*
* Wa_1409085225:tgl
* Wa_14010229206:tgl
@@ -1377,6 +1372,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
}
if (IS_TIGERLAKE(i915)) {
+ /* Wa_1606931601:tgl */
+ wa_masked_en(wal, GEN7_ROW_CHICKEN2, GEN12_DISABLE_EARLY_READ);
+
/* Wa_1409804808:tgl */
wa_masked_en(wal, GEN7_ROW_CHICKEN2,
GEN12_PUSH_CONST_DEREF_HOLD_DIS);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/14] drm/i915/tgl: Add Wa_1409085225, Wa_14010229206
From: Matt Atwood
Disable Push Constant buffer addition for TGL.
v2: typos, add additional Wa reference
v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit
message.
Bspec: 52890
Cc: Rafael Antognolli
Cc: Matt Roper
Reviewed-by: Matt Roper
Signed-off-by: Matt Atwood
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 0d80de88ccf3..1d1aa3967add 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1368,6 +1368,12 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_masked_en(wal,
GEN7_ROW_CHICKEN2,
GEN12_DISABLE_EARLY_READ);
+
+ /*
+* Wa_1409085225:tgl
+* Wa_14010229206:tgl
+*/
+ wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN12_DISABLE_TDL_PUSH);
}
if (IS_TIGERLAKE(i915)) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7edd5dfbd585..e2abd910ae80 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9158,6 +9158,9 @@ enum {
#define PUSH_CONSTANT_DEREF_DISABLE (1 << 8)
#define GEN11_TDL_CLOCK_GATING_FIX_DISABLE (1 << 1)
+#define GEN9_ROW_CHICKEN4 _MMIO(0xe48c)
+#define GEN12_DISABLE_TDL_PUSH REG_BIT(9)
+
#define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
#define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/14] drm/i915/tgl: Extend Wa_1409825376 stepping
This workaround is only fixed in C0 stepping to extend it to B0 too. BSpec: 52890 Cc: Radhakrishna Sripada Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 49484d5f5f84..e6d9ec124db8 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -6852,7 +6852,7 @@ static void tgl_init_clock_gating(struct drm_i915_private *dev_priv) I915_READ(POWERGATE_ENABLE) | vd_pg_enable); /* Wa_1409825376:tgl (pre-prod)*/ - if (IS_TGL_DISP_REVID(dev_priv, TGL_DISP_REVID_A0, TGL_DISP_REVID_A0)) + if (IS_TGL_DISP_REVID(dev_priv, TGL_DISP_REVID_A0, TGL_DISP_REVID_B0)) I915_WRITE(GEN9_CLKGATE_DIS_3, I915_READ(GEN9_CLKGATE_DIS_3) | TGL_VRH_GATING_DIS); } -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/14] drm/i915/tgl: Add note to Wa_1607297627
Add note about the confliting information in BSpec about this WA. BSpec: 52890 Acked-by: Matt Roper Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index bc0af522542b..143ff3daab0d 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1343,9 +1343,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal) GEN9_CTX_PREEMPT_REG, GEN12_DISABLE_POSH_BUSY_FF_DOP_CG); - /* Wa_1607030317:tgl */ - /* Wa_1607186500:tgl */ - /* Wa_1607297627:tgl */ + /* +* Wa_1607030317:tgl +* Wa_1607186500:tgl +* Wa_1607297627:tgl there is 3 entries for this WA on BSpec, 2 +* of then says it is fixed on B0 the other one says it is +* permanent +*/ wa_masked_en(wal, GEN6_RC_SLEEP_PSMI_CONTROL, GEN12_WAIT_FOR_EVENT_POWER_DOWN_DISABLE | -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 14/14] drm/i915/tgl: Implement Wa_1407901919
This will fix a memory coherence issue.
BSpec: 52890
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 20 +++-
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 164b5e82e3e3..b3bb3dd90f02 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -606,6 +606,12 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val,
IS_TGL_GT_REVID(engine->i915, TGL_GT_REVID_A0,
TGL_GT_REVID_A0) ? 0 : FF_MODE2_TDS_TIMER_MASK);
+
+ /* Wa_1407901919:tgl */
+ wa_add(wal, ICL_HDC_MODE, HDC_COHERENT_ACCESS_L1_CACHE_DIS |
+ HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W, 0,
+ HDC_COHERENT_ACCESS_L1_CACHE_DIS |
+ HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W);
}
static void
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e2abd910ae80..3f592636f982 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7892,15 +7892,17 @@ enum {
#define GEN8_LQSC_FLUSH_COHERENT_LINES(1 << 21)
/* GEN8 chicken */
-#define HDC_CHICKEN0 _MMIO(0x7300)
-#define CNL_HDC_CHICKEN0 _MMIO(0xE5F0)
-#define ICL_HDC_MODE _MMIO(0xE5F4)
-#define HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE(1 << 15)
-#define HDC_FENCE_DEST_SLM_DISABLE(1 << 14)
-#define HDC_DONOT_FETCH_MEM_WHEN_MASKED (1 << 11)
-#define HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT (1 << 5)
-#define HDC_FORCE_NON_COHERENT(1 << 4)
-#define HDC_BARRIER_PERFORMANCE_DISABLE (1 << 10)
+#define HDC_CHICKEN0 _MMIO(0x7300)
+#define CNL_HDC_CHICKEN0 _MMIO(0xE5F0)
+#define ICL_HDC_MODE _MMIO(0xE5F4)
+#define HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLEREG_BIT(15)
+#define HDC_FENCE_DEST_SLM_DISABLEREG_BIT(14)
+#define HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W REG_BIT(13)
+#define HDC_COHERENT_ACCESS_L1_CACHE_DIS REG_BIT(12)
+#define HDC_DONOT_FETCH_MEM_WHEN_MASKED REG_BIT(11)
+#define HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT REG_BIT(5)
+#define HDC_FORCE_NON_COHERENTREG_BIT(4)
+#define HDC_BARRIER_PERFORMANCE_DISABLE REG_BIT(10)
#define GEN8_HDC_CHICKEN1 _MMIO(0x7304)
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/14] drm/i915/tgl: Split GT and display workarounds
Spliting GT and display revisions id to correctly apply workarounds
because we have some issues that were fixed in display B0 but no
hardware was made with B0 stepping, so to keep consistent with BSpec
splitting it from GT and adding this adittional handling.
BSpec: 52890
BSpec: 44455
Cc: Matt Roper
Cc: James Ausmus
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +++---
drivers/gpu/drm/i915/i915_drv.h | 36 +--
drivers/gpu/drm/i915/intel_pm.c | 2 +-
5 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 6e25a1317161..82af963106ab 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5010,7 +5010,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private
*dev_priv)
const struct buddy_page_mask *table;
int i;
- if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
+ if (IS_TGL_DISP_REVID(dev_priv, TGL_DISP_REVID_A0, TGL_DISP_REVID_A0))
/* Wa_1409767108: tgl */
table = wa_1409767108_buddy_page_masks;
else
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 39b0125b7143..852981d533a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4124,7 +4124,7 @@ static int gen12_emit_flush_render(struct i915_request
*request,
/*
* Wa_1604544889:tgl
*/
- if (IS_TGL_REVID(request->i915, TGL_REVID_A0, TGL_REVID_A0)) {
+ if (IS_TGL_GT_REVID(request->i915, TGL_GT_REVID_A0,
TGL_GT_REVID_A0)) {
flags = 0;
flags |= PIPE_CONTROL_CS_STALL;
flags |= PIPE_CONTROL_HDC_PIPELINE_FLUSH;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 887e0dc701f7..bc6114b6dc8f 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -596,8 +596,8 @@ static void tgl_ctx_workarounds_init(struct intel_engine_cs
*engine,
* the read of FF_MODE2.
*/
wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val,
- IS_TGL_REVID(engine->i915, TGL_REVID_A0, TGL_REVID_A0) ? 0 :
- FF_MODE2_TDS_TIMER_MASK);
+ IS_TGL_GT_REVID(engine->i915, TGL_GT_REVID_A0,
+ TGL_GT_REVID_A0) ? 0 : FF_MODE2_TDS_TIMER_MASK);
}
static void
@@ -931,13 +931,13 @@ static void
tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
/* Wa_1409420604:tgl */
- if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0))
+ if (IS_TGL_GT_REVID(i915, TGL_GT_REVID_A0, TGL_GT_REVID_A0))
wa_write_or(wal,
SUBSLICE_UNIT_LEVEL_CLKGATE2,
CPSSUNIT_CLKGATE_DIS);
/* Wa_1409180338:tgl */
- if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0))
+ if (IS_TGL_GT_REVID(i915, TGL_GT_REVID_A0, TGL_GT_REVID_A0))
wa_write_or(wal,
SLICE_UNIT_LEVEL_CLKGATE,
L3_CLKGATE_DIS | L3_CR2X_CLKGATE_DIS);
@@ -1329,7 +1329,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
- if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
+ if (IS_TGL_GT_REVID(i915, TGL_GT_REVID_A0, TGL_GT_REVID_A0)) {
/* Wa_1606700617:tgl */
wa_masked_en(wal,
GEN9_CS_DEBUG_MODE1,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea13fc0b409b..4fa01f8d3f33 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1574,11 +1574,43 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define IS_ICL_REVID(p, since, until) \
(IS_ICELAKE(p) && IS_REVID(p, since, until))
-#define TGL_REVID_A0 0x0
+#define TGL_GT_REVID_A00x0
-#define IS_TGL_REVID(p, since, until) \
+#define IS_TGL_GT_REVID(p, since, until) \
(IS_TIGERLAKE(p) && IS_REVID(p, since, until))
+/*
+ * revid=0x0 = DISP_REVID_A0
+ * revid=0x1 = DISP_REVID_C0
+ * revid=0x2 = DISP_REVID_D0
+ *
+ * So ids bellow will not match PCI revid and the function bellow is used.
+ */
+#define TGL_DISP_REVID_A0 0x0
+#define TGL_DISP_REVID_B0 0x1
+#define TGL_DISP_REVID_C0 0x2
+#define TGL_DISP_REVID_D0 0x3
+
+static inline bool
+_tgl_disp_revid(struct drm_i915_private *p, u8 since, u8 until)
+{
+ const u8 gt2_disp_revid[] = {
+
[Intel-gfx] [PATCH v2 09/14] drm/i915/tgl: Extend Wa_1409767108 to B0
This Wa will also be needed by B0 stepping. BSpec: 52890 Signed-off-by: José Roberto de Souza --- 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 82af963106ab..134879385df6 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -5010,7 +5010,7 @@ static void tgl_bw_buddy_init(struct drm_i915_private *dev_priv) const struct buddy_page_mask *table; int i; - if (IS_TGL_DISP_REVID(dev_priv, TGL_DISP_REVID_A0, TGL_DISP_REVID_A0)) + if (IS_TGL_DISP_REVID(dev_priv, TGL_DISP_REVID_A0, TGL_DISP_REVID_B0)) /* Wa_1409767108: tgl */ table = wa_1409767108_buddy_page_masks; else -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/14] drm/i915/tgl: Add Wa number to WaAllowPMDepthAndInvocationCountAccessFromUMD
Just to make easier to check that the Wa was implemetend when comparing to the number in BSpec. BSpec: 52890 Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index b7b13372e287..164b5e82e3e3 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1259,6 +1259,7 @@ static void tgl_whitelist_build(struct intel_engine_cs *engine) case RENDER_CLASS: /* * WaAllowPMDepthAndInvocationCountAccessFromUMD:tgl +* Wa_1408556865:tgl * * This covers 4 registers which are next to one another : * - PS_INVOCATION_COUNT -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 12/14] drm/i915/tgl: Restrict Wa_1408615072 to GT A0 stepping
It is fixed in B0 stepping.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e6d9ec124db8..9df150f877b1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6838,8 +6838,9 @@ static void tgl_init_clock_gating(struct drm_i915_private
*dev_priv)
unsigned int i;
/* Wa_1408615072:tgl */
- intel_uncore_rmw(_priv->uncore, UNSLICE_UNIT_LEVEL_CLKGATE2,
-0, VSUNIT_CLKGATE_DIS_TGL);
+ if (IS_TGL_GT_REVID(dev_priv, TGL_GT_REVID_A0, TGL_GT_REVID_A0))
+ intel_uncore_rmw(_priv->uncore, UNSLICE_UNIT_LEVEL_CLKGATE2,
+0, VSUNIT_CLKGATE_DIS_TGL);
/* This is not a WA. Enable VD HCP & MFX_ENC powergate */
for (i = 0; i < I915_MAX_VCS; i++) {
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/14] drm/i915/tgl: Implement Wa_1409804808
This workaround the CS not done issue on PIPE_CONTROL.
v2:
- replaced BIT() by REG_BIT() in all GEN7_ROW_CHICKEN2() bits
- shortened the name of the new bit
BSpec: 52890
BSpec: 46218
Cc: Matt Roper
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index bc6114b6dc8f..8139f1443bd7 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1367,6 +1367,12 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
GEN12_DISABLE_EARLY_READ);
}
+ if (IS_TIGERLAKE(i915)) {
+ /* Wa_1409804808:tgl */
+ wa_masked_en(wal, GEN7_ROW_CHICKEN2,
+GEN12_PUSH_CONST_DEREF_HOLD_DIS);
+ }
+
if (IS_GEN(i915, 11)) {
/* This is not an Wa. Enable for better image quality */
wa_masked_en(wal,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f45b5e86ec63..7edd5dfbd585 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9149,8 +9149,9 @@ enum {
#define THROTTLE_12_5(7 << 2)
#define DISABLE_EARLY_EOT(1 << 1)
-#define GEN7_ROW_CHICKEN2 _MMIO(0xe4f4)
-#define GEN12_DISABLE_EARLY_READ BIT(14)
+#define GEN7_ROW_CHICKEN2 _MMIO(0xe4f4)
+#define GEN12_DISABLE_EARLY_READ REG_BIT(14)
+#define GEN12_PUSH_CONST_DEREF_HOLD_DIS REG_BIT(8)
#define GEN7_ROW_CHICKEN2_GT2 _MMIO(0xf4f4)
#define DOP_CLOCK_GATING_DISABLE (1 << 0)
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/14] drm/i915/tgl: Add note about Wa_1409142259
Different issues with the same fix, so justing adding
Wa_1409142259, Wa_1409252684, Wa_1409217633, Wa_1409207793,
Wa_1409178076 and 1408979724 to the comment so other devs can check if
this Was were implemetend with a simple grep.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index e7ca0eab2700..b7b13372e287 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -582,7 +582,15 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
{
u32 val;
- /* Wa_1409142259:tgl */
+ /*
+* Wa_1409142259:tgl
+* Wa_1409347922:tgl
+* Wa_1409252684:tgl
+* Wa_1409217633:tgl
+* Wa_1409207793:tgl
+* Wa_1409178076:tgl
+* Wa_1408979724:tgl
+*/
WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
GEN12_DISABLE_CPS_AWARE_COLOR_PIPE);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/14] drm/i915/tgl: Implement Wa_1806527549
This will whitelist the HIZ_CHICKEN register so mesa can disable the optimizations and avoid hang when using D16_UNORM. v2: moved to the right place and used the right function() (Chris) Cc: Matt Roper Cc: Rafael Antognolli Cc: Chris Wilson Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 8139f1443bd7..0d80de88ccf3 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1264,6 +1264,9 @@ static void tgl_whitelist_build(struct intel_engine_cs *engine) /* Wa_1808121037:tgl */ whitelist_reg(w, GEN7_COMMON_SLICE_CHICKEN1); + + /* Wa_1806527549:tgl */ + whitelist_reg(w, HIZ_CHICKEN); break; default: break; -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for 3 display pipes combination system support (rev4)
== Series Details == Series: 3 display pipes combination system support (rev4) URL : https://patchwork.freedesktop.org/series/72468/ State : success == Summary == CI Bug Log - changes from CI_DRM_7998_full -> Patchwork_16687_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16687_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-iclb2/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +12 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-iclb5/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-iclb3/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-skl7/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-skl9/igt@gem_exec_susp...@basic-s3.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#644]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-skl6/igt@gem_pp...@flink-and-close-vma-leak.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-skl8/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-kbl4/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-apl8/igt@i915_susp...@fence-restore-tiled2untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-b-cursor-dpms: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#54]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-dpms.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#34]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-skl8/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-skl6/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_psr@psr2_sprite_blt: - shard-tglb: [PASS][21] -> [SKIP][22] ([i915#668]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-tglb1/igt@kms_psr@psr2_sprite_blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-tglb1/igt@kms_psr@psr2_sprite_blt.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7998/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16687/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html * igt@perf_pmu@busy-vcs1: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#112080]) +12 similar issues [25]:
Re: [Intel-gfx] [PATCH 7/7] docs: gpu: i915.rst: fix warnings due to file renames
On Sat, Feb 22, 2020 at 10:00:07AM +0100, Mauro Carvalho Chehab wrote:
> Fix two warnings due to file rename:
>
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
> csr support for dmc ./drivers/gpu/drm/i915/intel_csr.c' failed with return
> code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
> ./drivers/gpu/drm/i915/intel_csr.c' failed with return code 2
>
> Fixes: 06d3ff6e7451 ("drm/i915: move intel_csr.[ch] under display/")
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Rodrigo Vivi
> ---
> Documentation/gpu/i915.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index e539c42a3e78..cc74e24ca3b5 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -207,10 +207,10 @@ DPIO
> CSR firmware support for DMC
>
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_csr.c
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c
> :doc: csr support for dmc
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_csr.c
> +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c
> :internal:
>
> Video BIOS Table (VBT)
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 5.6-rc2
Still the same in rc3 Hopefully patch will land in rc4... --- Srdačan pozdrav/Best regards/Freundliche Grüße/Cordialement, Siniša Bandin On 21.02.2020 03:23, Souza, Jose wrote: We have a fix for this issue, still going through review. https://gitlab.freedesktop.org/drm/intel/issues/1151 On Fri, 2020-02-21 at 11:38 +1000, Dave Airlie wrote: looping in intel-gfx + Jani. On Tue, 18 Feb 2020 at 05:20, sinisa wrote: > > On 2020-02-16 22:32, Linus Torvalds wrote: > > ... > > Chris Wilson (19): > > drm/i915/pmu: Correct the rc6 offset upon enabling > > drm/i915/gem: Take local vma references for the parser > > drm/i915/selftests: Add a mock i915_vma to the mock_ring > > drm/i915/gt: Use the BIT when checking the flags, not the > index > > drm/i915/execlists: Leave resetting ring to intel_ring > > drm/i915/gem: Store mmap_offsets in an rbtree rather than > a > plain list > > drm/i915: Don't show the blank process name for > internal/simulated errors > > drm/i915/gem: Detect overflow in calculating dumb buffer > size > > drm/i915: Check activity on i915_vma after confirming > pin_count==0 > > drm/i915: Stub out i915_gpu_coredump_put > > drm/i915: Tighten atomicity of i915_active_acquire vs > i915_active_release > > drm/i915/gt: Acquire ce->active before ce->pin_count/ce- > >pin_mutex > > drm/i915/gem: Tighten checks and acquiring the mmap object > > drm/i915: Keep track of request among the scheduling lists > > drm/i915/gt: Allow temporary suspension of inflight > requests > > drm/i915/execlists: Offline error capture > > drm/i915/execlists: Take a reference while capturing the > guilty > request > > drm/i915/execlists: Reclaim the hanging virtual request > > drm/i915: Mark the removal of the i915_request from the > sched.link > > ... > > Something from here makes my Toshiba Portege Z30-A (CPU is i5-4210U > with > integrated graphics) to to only get black screen when loading i915 > driver. > > Happens the same in rc1 and rc2, works OK with all previous > kernels. > > > Here is relevant part of the dmesg output: > > > [4.643848] i915 :00:02.0: vgaarb: deactivate vga console > [4.645363] Console: switching to colour dummy device 80x25 > [4.667372] [drm] Supports vblank timestamp caching Rev 2 > (21.10.2013). > [4.667379] [drm] Driver supports precise vblank timestamp > query. > [4.667743] i915 :00:02.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=io+mem:owns=io+mem > [4.682355] [ cut here ] > [4.682389] WARNING: CPU: 3 PID: 459 at > drivers/gpu/drm/drm_atomic.c:296 > drm_atomic_get_crtc_state+0xf8/0x110 [drm] > [4.682394] Modules linked in: iTCO_wdt iTCO_vendor_support > nls_iso8859_1 snd_hda_codec_realtek i915(+) fuse nls_cp437 > snd_hda_codec_generic vfat fat iwlwifi uvcvideo ledtrig_audio > aesni_intel(+) drm_kms_helper videobuf2_vmalloc crypto_simd > snd_hda_intel videobuf2_memops cec snd_intel_dspcfg rc_core > videobuf2_v4l2 cryptd snd_hda_codec glue_helper videobuf2_common > cfg80211 drm pcspkr videodev snd_hda_core wmi_bmof snd_hwdep > snd_pcm > toshiba_acpi mc e1000e snd_timer sparse_keymap fb_sys_fops > syscopyarea > sysfillrect industrialio lpc_ich snd sysimgblt i2c_algo_bit > toshiba_bluetooth soundcore thermal rfkill intel_smartconnect ac > button > xfs libcrc32c xhci_pci xhci_hcd rtsx_pci_sdmmc mmc_core ehci_pci > ehci_hcd usbcore crc32c_intel rtsx_pci serio_raw battery wmi video > l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppox sg > ppp_mppe ppp_generic slhc libarc4 dm_multipath dm_mod scsi_dh_rdac > scsi_dh_emc scsi_dh_alua > [4.682455] CPU: 3 PID: 459 Comm: systemd-udevd Not tainted > 5.6.0-rc2-1.g327abc9-default #1 openSUSE Tumbleweed (unreleased) > [4.682460] Hardware name: TOSHIBA PORTEGE Z30-A/PORTEGE Z30-A, > BIOS > Version 4.30 04/26/2018 > [4.682486] RIP: 0010:drm_atomic_get_crtc_state+0xf8/0x110 [drm] > [4.682490] Code: 89 2c 11 48 89 98 f0 01 00 00 48 8b 4d 20 8b > 55 60 > e8 2c aa 00 00 48 8b 04 24 48 83 c4 08 5b 5d 41 5c c3 48 98 e9 4e > ff ff > ff <0f> 0b e9 28 ff ff ff 48 c7 c0 f4 ff ff ff e9 3b ff ff ff 0f 1f > 44 > [4.682497] RSP: :aa5bc04338a8 EFLAGS: 00010246 > [4.682500] RAX: RBX: 9c97862c1000 RCX: > 9c979101ed08 > [4.682504] RDX: 002d RSI: RDI: > 9c97862c1000 > [4.682507] RBP: 9c97862c7800 R08: 0079 R09: > 0079 > [4.682510] R10: 002d R11: 0005 R12: > > [4.682513] R13: 9c97862c7800 R14: 9c97862c0800 R15: > c0ee0f80 > [4.682517] FS: 7f65d2c92dc0() > GS:9c9792ec() > knlGS: > [4.682521] CS: 0010 DS: ES: CR0: 80050033 > [4.682524] CR2: 7f016d25b610 CR3: 00030f634004 CR4: >
Re: [Intel-gfx] [PATCH 37/51] drm/rockchip: Drop explicit drm_mode_config_cleanup call
On Fri, Feb 21, 2020 at 10:04 PM Daniel Vetter wrote: > > It's (almost, there's some iommu stuff without significance) right > above the drm_dev_put(). > > This is made possible by a preceeding patch which added a drmm_ > cleanup action to drm_mode_config_init(), hence all we need to do to > ensure that drm_mode_config_cleanup() is run on final drm_device > cleanup is check the new error code for _init(). > > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... > > v2: Explain why this cleanup is possible (Laurent). > > Cc: Laurent Pinchart > Signed-off-by: Daniel Vetter > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > --- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 10 +++--- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > index 20ecb1508a22..d0eba21eebc9 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > @@ -135,7 +135,9 @@ static int rockchip_drm_bind(struct device *dev) > if (ret) > goto err_free; > > - drm_mode_config_init(drm_dev); > + ret = drm_mode_config_init(drm_dev); > + if (ret) > + goto err_free; Shouldn't the goto label be err_mode_config_cleanup here? Otherwise this error path misses the call to rockchip_iommu_cleanup(). > > rockchip_drm_mode_config_init(drm_dev); > > @@ -174,11 +176,8 @@ static int rockchip_drm_bind(struct device *dev) > err_unbind_all: > component_unbind_all(dev, drm_dev); > err_mode_config_cleanup: > - drm_mode_config_cleanup(drm_dev); > rockchip_iommu_cleanup(drm_dev); > err_free: > - drm_dev->dev_private = NULL; > - dev_set_drvdata(dev, NULL); > drm_dev_put(drm_dev); > return ret; > } On Fri, Feb 21, 2020 at 10:04 PM Daniel Vetter wrote: > > It's (almost, there's some iommu stuff without significance) right > above the drm_dev_put(). > > This is made possible by a preceeding patch which added a drmm_ > cleanup action to drm_mode_config_init(), hence all we need to do to > ensure that drm_mode_config_cleanup() is run on final drm_device > cleanup is check the new error code for _init(). > > Aside: Another driver with a bit much devm_kzalloc, which should > probably use drmm_kzalloc instead ... > > v2: Explain why this cleanup is possible (Laurent). > > Cc: Laurent Pinchart > Signed-off-by: Daniel Vetter > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > --- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 10 +++--- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > index 20ecb1508a22..d0eba21eebc9 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c > @@ -135,7 +135,9 @@ static int rockchip_drm_bind(struct device *dev) > if (ret) > goto err_free; > > - drm_mode_config_init(drm_dev); > + ret = drm_mode_config_init(drm_dev); > + if (ret) > + goto err_free; > > rockchip_drm_mode_config_init(drm_dev); > > @@ -174,11 +176,8 @@ static int rockchip_drm_bind(struct device *dev) > err_unbind_all: > component_unbind_all(dev, drm_dev); > err_mode_config_cleanup: > - drm_mode_config_cleanup(drm_dev); > rockchip_iommu_cleanup(drm_dev); > err_free: > - drm_dev->dev_private = NULL; > - dev_set_drvdata(dev, NULL); > drm_dev_put(drm_dev); > return ret; > } > @@ -194,11 +193,8 @@ static void rockchip_drm_unbind(struct device *dev) > > drm_atomic_helper_shutdown(drm_dev); > component_unbind_all(dev, drm_dev); > - drm_mode_config_cleanup(drm_dev); > rockchip_iommu_cleanup(drm_dev); > > - drm_dev->dev_private = NULL; > - dev_set_drvdata(dev, NULL); > drm_dev_put(drm_dev); > } > > -- > 2.24.1 > > > ___ > Linux-rockchip mailing list > linux-rockc...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip ___ 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: split intel_modeset_init() to pre/post irq install
== Series Details == Series: drm/i915: split intel_modeset_init() to pre/post irq install URL : https://patchwork.freedesktop.org/series/73849/ State : success == Summary == CI Bug Log - changes from CI_DRM_7997_full -> Patchwork_16686_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16686_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@processes: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#570] / [i915#679]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-glk3/igt@gem_ctx_persiste...@processes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-glk2/igt@gem_ctx_persiste...@processes.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +13 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-iclb7/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@pi-userfault-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-iclb5/igt@gem_exec_sched...@pi-userfault-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-iclb1/igt@gem_exec_sched...@pi-userfault-bsd.html * igt@gem_exec_schedule@preempt-self-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-iclb8/igt@gem_exec_sched...@preempt-self-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-iclb4/igt@gem_exec_sched...@preempt-self-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#644]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#644]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-tglb7/igt@gem_pp...@flink-and-close-vma-leak.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-tglb6/igt@gem_pp...@flink-and-close-vma-leak.html - shard-skl: [PASS][13] -> [FAIL][14] ([i915#644]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-skl1/igt@gem_pp...@flink-and-close-vma-leak.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-skl10/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_workarounds@suspend-resume-fd: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-skl5/igt@gem_workarou...@suspend-resume-fd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-skl6/igt@gem_workarou...@suspend-resume-fd.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#72]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-glk7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_flip@flip-vs-suspend: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-apl8/igt@kms_f...@flip-vs-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-apl1/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip_tiling@flip-y-tiled: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#699]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-skl9/igt@kms_flip_til...@flip-y-tiled.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16686/shard-skl7/igt@kms_flip_til...@flip-y-tiled.html * igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-wc: - shard-tglb: [PASS][25] -> [SKIP][26] ([i915#668]) +3 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7997/shard-tglb7/igt@kms_frontbuffer_track...@psr-rgb565-draw-mmap-wc.html [26]:
Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Fix error reported by I915_PARAM_HUC_STATUS
On 25.02.2020 08:49, Ye, Tony wrote:
>
>
> On 2/21/2020 11:32 PM, Michal Wajdeczko wrote:
>> From commit 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt over i915
>> in GuC/HuC paths") we stopped using HUC_STATUS error -ENODEV only
>> to indicate lack of HuC hardware and we started to use this error
>> also for all other cases when HuC was not in use or supported.
>>
>> Fix that by relying again on HAS_GT_UC macro, since currently
>> used function intel_huc_is_supported() is based on HuC firmware
>> support which could be unsupported also due to force disabled
>> GuC firmware.
>>
>> v2: use 0 only for disabled, add more error codes for other failures
>>
>> Signed-off-by: Michal Wajdeczko
>> Cc: Daniele Ceraolo Spurio
>> Cc: Michal Wajdeczko
>> Cc: Tony Ye
>> Cc: Robert M. Fosha
>> Reviewed-by: Daniele Ceraolo Spurio #v1
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 29 +-
>> 1 file changed, 24 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
>> index a74b65694512..301bb5d5e59a 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
>> @@ -200,9 +200,13 @@ int intel_huc_auth(struct intel_huc *huc)
>> * This function reads status register to verify if HuC
>> * firmware was successfully loaded.
>> *
>> - * Returns: 1 if HuC firmware is loaded and verified,
>> - * 0 if HuC firmware is not loaded and -ENODEV if HuC
>> - * is not present on this platform.
>> + * Returns:
>> + * * 1 if HuC firmware is loaded and verified,
>> + * * 0 if HuC firmware was disabled,
>> + * * -ENODEV if HuC is not present on this platform,
>> + * * -ENOPKG if HuC firmware was not installed,
>> + * * -ENOEXEC if HuC firmware is invalid,
>> + * * -EACCES if HuC firmware was not authenticated.
>> */
>> int intel_huc_check_status(struct intel_huc *huc)
>> {
>> @@ -210,11 +214,26 @@ int intel_huc_check_status(struct intel_huc *huc)
>> intel_wakeref_t wakeref;
>> u32 status = 0;
>> - if (!intel_huc_is_supported(huc))
>> + if (!HAS_GT_UC(gt->i915))
>> return -ENODEV;
>> + switch (__intel_uc_fw_status(>fw)) {
>> + case INTEL_UC_FIRMWARE_NOT_SUPPORTED:
>> + case INTEL_UC_FIRMWARE_DISABLED:
>> + return 0;
>> + case INTEL_UC_FIRMWARE_MISSING:
>> + return -ENOPKG;
>> + case INTEL_UC_FIRMWARE_ERROR:
>> + return -ENOEXEC;
>
> What about INTEL_UC_FIRMWARE_FAIL?
I assumed that we don't need to handle that case here, since we are
still checking HuC status register below.
But if you want we can improve:
1) return early if FAIL, then check register anyway
2) return early if FAIL, trust fw state and return 1 without checking
register (as same register was already checked when we mark fw state as
RUNNING)
>
> Regards,
> Tony
>
>> + default:
>> + break;
>> + }
>> +
>> with_intel_runtime_pm(gt->uncore->rpm, wakeref)
>> status = intel_uncore_read(gt->uncore, huc->status.reg);
>> - return (status & huc->status.mask) == huc->status.value;
>> + if ((status & huc->status.mask) != huc->status.value)
>> + return -EACCES;
>> +
>> + return 1;
>> }
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm: Nuke mode->vrefresh
On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä wrote: > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples. That's impressive :D > Unfortunately it found a lot of strange stuff: I will answer for the weirdness I caused. I have long suspected that a whole bunch of the "simple" displays are not simple but contains a display controller and memory. That means that the speed over the link to the display and actual refresh rate on the actual display is asymmetric because well we are just updating a RAM, the resolution just limits how much data we are sending, the clock limits the speed on the bus over to the RAM on the other side. In most cases I thing the clock is the way to go. > panel-sony-acx424akp.c:51/sony_acx424akp_vid_mode: 60 vs. 727 (.clock=33 > .htotal=480 + 15 + 0 + 15 .vtotal=864 + 14 + 1 + 11) I suspect clock should be adjusted after vfresh = 60 here instead of the other way around. I couldn't quite test the video mode, but the vendor driver (no documentation ) does state 330 MHz which seems a bit high. Just drop vrefresh for now. > panel-sony-acx424akp.c:71/sony_acx424akp_cmd_mode: 60 vs. 711 (.clock=420160 > .htotal=480 + 154 + 16 + 32 .vtotal=864 + 1 + 1 + 1) You can override this ignoring the vrefresh, this is a command-mode only, and in command mode the refresh doesn't come into play, or is very high and limited by a bunch of other overhead than just the resolution. The command mode HS clock is @420+ MHz indeed. Tests showed around 116 Hz for this particular display in practice with continuous updates. > panel-ilitek-ili9322.c:543/srgb_320x240_mode: 60 vs. 10168 (.clock=2453500 > .htotal=320 + 359 + 1 + 241 .vtotal=262) > panel-ilitek-ili9322.c:587/yuv_640x320_mode: 60 vs. 7768 (.clock=2454000 > .htotal=640 + 252 + 1 + 28 .vtotal=320 + 4 + 1 + 18) > panel-ilitek-ili9322.c:616/itu_r_bt_656_640_mode: 60 vs. 5358 (.clock=2454000 > .htotal=640 + 3 + 1 + 272 .vtotal=500) > panel-ilitek-ili9322.c:557/srgb_360x240_mode: 60 vs. 16178 (.clock=270 > .htotal=360 + 35 + 1 + 241 .vtotal=262) > panel-ilitek-ili9322.c:601/yuv_720x360_mode: 60 vs. 7071 (.clock=270 > .htotal=720 + 252 + 1 + 24 .vtotal=360 + 4 + 1 + 18) > panel-ilitek-ili9322.c:631/itu_r_bt_656_720_mode: 60 vs. 5422 (.clock=270 > .htotal=720 + 3 + 1 + 272 .vtotal=500) > panel-ilitek-ili9322.c:572/prgb_320x240_mode: 60 vs. 59725 (.clock=640 > .htotal=320 + 38 + 1 + 50 .vtotal=262) This is the datasheet if you want to take a look: https://dflund.se/~triad/krad/dlink-dir-685/ILI9322DS_V1.12.pdf The one platform using this is using the 8 bit ITU-R BT.656 640Y 320CbCr mode which (I think) is similar to DSI command mode again: there is a stream of data in a burst and you decide how often you want to send it because the panel always has backing memory and the speed out to the physical display is something completely different. You can safely delete vrefresh from all of these sites. > panel-arm-versatile.c:161/versatile_panels[]: 60 vs. 61 (.clock=25000 > .htotal=640 + 24 + 96 + 24 .vtotal=480 + 11 + 2 + 32) > panel-arm-versatile.c:208/versatile_panels[]: 116 vs. 59 (.clock=5400 > .htotal=240 + 10 + 10 + 20 .vtotal=320 + 2 + 2 + 2) > panel-arm-versatile.c:184/versatile_panels[]: 390 vs. 1523 (.clock=62500 > .htotal=176 + 2 + 3 + 3 .vtotal=220 + 0 + 2 + 1) The only driver drivers/gpu/drm/pl111/pl111_display.c Uses mode->clock so just drop vrefresh. Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Add request throughput measurement to perf
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
drivers/gpu/drm/i915/selftests/i915_request.c | 280 +-
2 files changed, 280 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
index 3bf7f53e9924..d8da142985eb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
+++ b/drivers/gpu/drm/i915/selftests/i915_perf_selftests.h
@@ -16,5 +16,6 @@
* Tests are executed in order by igt/i915_selftest
*/
selftest(engine_cs, intel_engine_cs_perf_selftests)
+selftest(request, i915_request_perf_selftests)
selftest(blt, i915_gem_object_blt_perf_selftests)
selftest(region, intel_memory_region_perf_selftests)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..91f67995f0ac 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include "gem/i915_gem_pm.h"
#include "gem/selftests/mock_context.h"
@@ -1233,7 +1234,7 @@ static int live_parallel_engines(void *arg)
struct igt_live_test t;
unsigned int idx;
- snprintf(name, sizeof(name), "%pS", fn);
+ snprintf(name, sizeof(name), "%ps", *fn);
err = igt_live_test_begin(, i915, __func__, name);
if (err)
break;
@@ -1470,3 +1471,280 @@ int i915_request_live_selftests(struct drm_i915_private
*i915)
return i915_subtests(tests, i915);
}
+
+struct perf_parallel {
+ struct intel_engine_cs *engine;
+ unsigned long count;
+ ktime_t time;
+ ktime_t busy;
+ u64 runtime;
+};
+
+static int switch_to_kernel_sync(struct intel_context *ce, int err)
+{
+ struct i915_request *rq;
+ struct dma_fence *fence;
+
+ rq = intel_engine_create_kernel_request(ce->engine);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ fence = i915_active_fence_get(>timeline->last_request);
+ if (fence) {
+ i915_request_await_dma_fence(rq, fence);
+ dma_fence_put(fence);
+ }
+
+ rq = i915_request_get(rq);
+ i915_request_add(rq);
+ if (i915_request_wait(rq, 0, HZ / 2) < 0 && !err)
+ err = -ETIME;
+ i915_request_put(rq);
+
+ while (!err && !intel_engine_is_idle(ce->engine))
+ intel_engine_flush_submission(ce->engine);
+
+ return err;
+}
+
+static int perf_sync(void *arg)
+{
+ struct perf_parallel *p = arg;
+ struct intel_engine_cs *engine = p->engine;
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+ bool busy;
+ int err = 0;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ err = intel_context_pin(ce);
+ if (err) {
+ intel_context_put(ce);
+ return err;
+ }
+
+ busy = false;
+ if (intel_engine_supports_stats(engine) &&
+ !intel_enable_engine_stats(engine)) {
+ p->busy = intel_engine_get_busy_time(engine);
+ busy = true;
+ }
+
+ p->time = ktime_get();
+ count = 0;
+ do {
+ struct i915_request *rq;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ break;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ err = 0;
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ break;
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+ p->time = ktime_sub(ktime_get(), p->time);
+
+ if (busy) {
+ p->busy = ktime_sub(intel_engine_get_busy_time(engine),
+ p->busy);
+ intel_disable_engine_stats(engine);
+ }
+
+ err = switch_to_kernel_sync(ce, err);
+ p->runtime = intel_context_get_total_runtime_ns(ce);
+ p->count = count;
+
+ intel_context_unpin(ce);
+ intel_context_put(ce);
+ return err;
+}
+
+static int perf_many(void *arg)
+{
+ struct perf_parallel *p = arg;
+ struct intel_engine_cs *engine = p->engine;
+ struct intel_context *ce;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+ int err = 0;
+ bool busy;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce))
+
Re: [Intel-gfx] [PATCH] drm/i915: stop assigning drm->dev_private pointer
On 2020-02-24 13:33:12, Jani Nikula wrote: > We no longer need or use it as we subclass struct drm_device in our > struct drm_i915_private, and can always use to_i915() to get at > i915. Stop assigning the pointer to catch anyone trying to add new users > for ->dev_private. > > Cc: Chris Wilson > Signed-off-by: Jani Nikula Reviewed-by: Dale B Stimson > --- > drivers/gpu/drm/i915/i915_drv.c | 2 -- > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 - > 2 files changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 4034e431cc4c..d5aed3b7d7e3 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1372,8 +1372,6 @@ i915_driver_create(struct pci_dev *pdev, const struct > pci_device_id *ent) > return ERR_PTR(err); > } > > - i915->drm.dev_private = i915; > - > i915->drm.pdev = pdev; > pci_set_drvdata(pdev, i915); > > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > index 3b8986983afc..754d0eb6beaa 100644 > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > @@ -144,7 +144,6 @@ struct drm_i915_private *mock_gem_device(void) > goto put_device; > } > i915->drm.pdev = pdev; > - i915->drm.dev_private = i915; > > intel_runtime_pm_init_early(>runtime_pm); > > -- > 2.20.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 04/12] drm: Nuke mode->vrefresh
On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> > On 25.02.2020 12:21, Ville Syrjälä wrote:
> > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> > >> On 19.02.2020 21:35, Ville Syrjala wrote:
> > >>> From: Ville Syrjälä
> > >>>
> > >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> > >>> a bit of space and avoids the cached value getting out of sync
> > >>> with reality.
> > >>>
> > >>> Mostly done with cocci, with the following manual fixups:
> > >>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> > >>> - Fix __MODE() macro in ch7006_mode.c
> > >>> - Fix DRM_MODE_ARG() macro in drm_modes.h
> > >>> - Remove leftover comment from samsung_s6d16d0_mode
> > >> ...
> > >>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
> > >>> b/drivers/gpu/drm/panel/panel-arm-versatile.c
> > >>> index 41444a73c980..47b37fef7ee8 100644
> > >>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> > >>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> > >>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type
> > >>> versatile_panels[] = {
> > >>> .vsync_start = 240 + 5,
> > >>> .vsync_end = 240 + 5 + 6,
> > >>> .vtotal = 240 + 5 + 6 + 5,
> > >>> - .vrefresh = 116,
> > >>
> > >> Are you sure vrefresh calculated (from totals and clock) is different
> > >> than this field? If not, we risk regressions.
> > >>
> > >> This case is OK, but there is plenty other cases.
> > > IIRC I did spot check a few of them. But which code exactly do you think
> > > is abusing vrefresh and thus could break?
> >
> >
> > I guess suspect/potential victim is every code which uses
> > drm_mode_vrefresh - after this patch the function can return different
> > value(if there are differences between provided and calculated vrefresh).
> >
> > Quick examples where output of this function matters:
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
>
> Already looks quite sketchy due to rounding.
>
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
>
> msleep() is in no way accurate so looks rather sketchy as well.
>
> > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
>
> Another thing that suffers from rounding issues.
>
> So to me these all look like code that someone should fix regardless.
OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples.
Unfortunately it found a lot of strange stuff:
panel-sony-acx424akp.c:51/sony_acx424akp_vid_mode: 60 vs. 727 (.clock=33
.htotal=480 + 15 + 0 + 15 .vtotal=864 + 14 + 1 + 11)
panel-sony-acx424akp.c:71/sony_acx424akp_cmd_mode: 60 vs. 711 (.clock=420160
.htotal=480 + 154 + 16 + 32 .vtotal=864 + 1 + 1 + 1)
panel-ilitek-ili9322.c:543/srgb_320x240_mode: 60 vs. 10168 (.clock=2453500
.htotal=320 + 359 + 1 + 241 .vtotal=262)
panel-ilitek-ili9322.c:587/yuv_640x320_mode: 60 vs. 7768 (.clock=2454000
.htotal=640 + 252 + 1 + 28 .vtotal=320 + 4 + 1 + 18)
panel-ilitek-ili9322.c:616/itu_r_bt_656_640_mode: 60 vs. 5358 (.clock=2454000
.htotal=640 + 3 + 1 + 272 .vtotal=500)
panel-ilitek-ili9322.c:557/srgb_360x240_mode: 60 vs. 16178 (.clock=270
.htotal=360 + 35 + 1 + 241 .vtotal=262)
panel-ilitek-ili9322.c:601/yuv_720x360_mode: 60 vs. 7071 (.clock=270
.htotal=720 + 252 + 1 + 24 .vtotal=360 + 4 + 1 + 18)
panel-ilitek-ili9322.c:631/itu_r_bt_656_720_mode: 60 vs. 5422 (.clock=270
.htotal=720 + 3 + 1 + 272 .vtotal=500)
panel-ilitek-ili9322.c:572/prgb_320x240_mode: 60 vs. 59725 (.clock=640
.htotal=320 + 38 + 1 + 50 .vtotal=262)
panel-lg-lg4573.c:200/default_mode: 60 vs. 57 (.clock=27000 .htotal=480 + 10 +
59 + 10 .vtotal=800 + 15 + 15 + 15)
panel-sitronix-st7789v.c:159/default_mode: 60 vs. 70 (.clock=7000 .htotal=240 +
38 + 10 + 10 .vtotal=320 + 8 + 4 + 4)
panel-arm-versatile.c:161/versatile_panels[]: 60 vs. 61 (.clock=25000
.htotal=640 + 24 + 96 + 24 .vtotal=480 + 11 + 2 + 32)
panel-arm-versatile.c:208/versatile_panels[]: 116 vs. 59 (.clock=5400
.htotal=240 + 10 + 10 + 20 .vtotal=320 + 2 + 2 + 2)
panel-arm-versatile.c:184/versatile_panels[]: 390 vs. 1523 (.clock=62500
.htotal=176 + 2 + 3 + 3 .vtotal=220 + 0 + 2 + 1)
panel-leadtek-ltk500hd1829.c:380/default_mode: 60 vs. 36 (.clock=41600
.htotal=720 + 50 + 50 + 50 .vtotal=1280 + 30 + 4 + 12)
panel-feixin-k101-im2ba02.c:394/k101_im2ba02_default_mode: 60 vs. 62
(.clock=7 .htotal=800 + 20 + 20 + 20 .vtotal=1280 + 16 + 4 + 4)
panel-simple.c:1305/edt_etm043080dh6gp_mode: 60 vs. 67 (.clock=10870
.htotal=480 + 8 + 4 + 41 .vtotal=288 + 2 + 4 + 10)
panel-simple.c:3881/lg_acx467akm_7_mode: 60 vs. 72 (.clock=15 .htotal=1080
+ 2 + 2 + 2 .vtotal=1920 + 2 + 2 + 2)
panel-simple.c:2509/ortustech_com37h3m_mode: 60 vs. 67
[Intel-gfx] [CI 2/3] drm/i915: Allow userspace to specify ringsize on construction
No good reason why we must always use a static ringsize, so let
userspace select one during construction.
Link: https://github.com/intel/compute-runtime/pull/261
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Steve Carbonari
Reviewed-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_context.c | 110 --
drivers/gpu/drm/i915/gt/intel_context_param.c | 63 ++
drivers/gpu/drm/i915/gt/intel_context_param.h | 14 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
include/uapi/drm/i915_drm.h | 21
6 files changed, 202 insertions(+), 8 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_context_param.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bc28c31c4f78..9db81b9ac0f3 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -82,6 +82,7 @@ gt-y += \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
+ gt/intel_context_param.o \
gt/intel_context_sseu.o \
gt/intel_engine_cs.o \
gt/intel_engine_heartbeat.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index adcebf22a3d3..b24ee8e104cf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -71,6 +71,7 @@
#include "gt/gen6_ppgtt.h"
#include "gt/intel_context.h"
+#include "gt/intel_context_param.h"
#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_ring.h"
@@ -668,23 +669,30 @@ __create_context(struct drm_i915_private *i915)
return ERR_PTR(err);
}
-static void
+static int
context_apply_all(struct i915_gem_context *ctx,
- void (*fn)(struct intel_context *ce, void *data),
+ int (*fn)(struct intel_context *ce, void *data),
void *data)
{
struct i915_gem_engines_iter it;
struct intel_context *ce;
+ int err = 0;
- for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it)
- fn(ce, data);
+ for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
+ err = fn(ce, data);
+ if (err)
+ break;
+ }
i915_gem_context_unlock_engines(ctx);
+
+ return err;
}
-static void __apply_ppgtt(struct intel_context *ce, void *vm)
+static int __apply_ppgtt(struct intel_context *ce, void *vm)
{
i915_vm_put(ce->vm);
ce->vm = i915_vm_get(vm);
+ return 0;
}
static struct i915_address_space *
@@ -722,9 +730,10 @@ static void __set_timeline(struct intel_timeline **dst,
intel_timeline_put(old);
}
-static void __apply_timeline(struct intel_context *ce, void *timeline)
+static int __apply_timeline(struct intel_context *ce, void *timeline)
{
__set_timeline(>timeline, timeline);
+ return 0;
}
static void __assign_timeline(struct i915_gem_context *ctx,
@@ -1215,6 +1224,63 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
return err;
}
+static int __apply_ringsize(struct intel_context *ce, void *sz)
+{
+ return intel_context_set_ring_size(ce, (unsigned long)sz);
+}
+
+static int set_ringsize(struct i915_gem_context *ctx,
+ struct drm_i915_gem_context_param *args)
+{
+ if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
+ return -ENODEV;
+
+ if (args->size)
+ return -EINVAL;
+
+ if (!IS_ALIGNED(args->value, I915_GTT_PAGE_SIZE))
+ return -EINVAL;
+
+ if (args->value < I915_GTT_PAGE_SIZE)
+ return -EINVAL;
+
+ if (args->value > 128 * I915_GTT_PAGE_SIZE)
+ return -EINVAL;
+
+ return context_apply_all(ctx,
+__apply_ringsize,
+__intel_context_ring_size(args->value));
+}
+
+static int __get_ringsize(struct intel_context *ce, void *arg)
+{
+ long sz;
+
+ sz = intel_context_get_ring_size(ce);
+ GEM_BUG_ON(sz > INT_MAX);
+
+ return sz; /* stop on first engine */
+}
+
+static int get_ringsize(struct i915_gem_context *ctx,
+ struct drm_i915_gem_context_param *args)
+{
+ int sz;
+
+ if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
+ return -ENODEV;
+
+ if (args->size)
+ return -EINVAL;
+
+ sz = context_apply_all(ctx, __get_ringsize, NULL);
+ if (sz < 0)
+ return sz;
+
+ args->value = sz;
+ return 0;
+}
+
static int
user_to_context_sseu(struct drm_i915_private *i915,
const struct drm_i915_gem_context_param_sseu *user,
@@ -1852,17 +1918,19 @@ set_persistence(struct i915_gem_context *ctx,
return
[Intel-gfx] [CI 3/3] drm/i915/gem: Honour O_NONBLOCK before throttling execbuf submissions
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas Lahtinen
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Steve Carbonari
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4f9c1f5a4ded..fe1e50937fe2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2327,15 +2327,22 @@ static int __eb_pin_engine(struct i915_execbuffer *eb,
struct intel_context *ce)
intel_context_timeline_unlock(tl);
if (rq) {
- if (i915_request_wait(rq,
- I915_WAIT_INTERRUPTIBLE,
- MAX_SCHEDULE_TIMEOUT) < 0) {
- i915_request_put(rq);
- err = -EINTR;
- goto err_exit;
- }
+ bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
+ long timeout;
+
+ timeout = MAX_SCHEDULE_TIMEOUT;
+ if (nonblock)
+ timeout = 0;
+ timeout = i915_request_wait(rq,
+ I915_WAIT_INTERRUPTIBLE,
+ timeout);
i915_request_put(rq);
+
+ if (timeout < 0) {
+ err = nonblock ? -EWOULDBLOCK : timeout;
+ goto err_exit;
+ }
}
eb->engine = ce->engine;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915: Flush idle barriers when waiting
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
Cc: Steve Carbonari
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 42 ++
drivers/gpu/drm/i915/selftests/i915_active.c | 46
2 files changed, 79 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 992b00fc5745..0b12d5023800 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -7,6 +7,7 @@
#include
#include "gt/intel_context.h"
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_ring.h"
@@ -460,26 +461,49 @@ static void enable_signaling(struct i915_active_fence
*active)
dma_fence_put(fence);
}
-int i915_active_wait(struct i915_active *ref)
+static int flush_barrier(struct active_node *it)
{
- struct active_node *it, *n;
- int err = 0;
+ struct intel_engine_cs *engine;
- might_sleep();
+ if (likely(!is_barrier(>base)))
+ return 0;
- if (!i915_active_acquire_if_busy(ref))
+ engine = __barrier_to_engine(it);
+ smp_rmb(); /* serialise with add_active_barriers */
+ if (!is_barrier(>base))
return 0;
- /* Flush lazy signals */
+ return intel_engine_flush_barriers(engine);
+}
+
+static int flush_lazy_signals(struct i915_active *ref)
+{
+ struct active_node *it, *n;
+ int err = 0;
+
enable_signaling(>excl);
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
- if (is_barrier(>base)) /* unconnected idle barrier */
- continue;
+ err = flush_barrier(it); /* unconnected idle barrier? */
+ if (err)
+ break;
enable_signaling(>base);
}
- /* Any fence added after the wait begins will not be auto-signaled */
+ return err;
+}
+
+int i915_active_wait(struct i915_active *ref)
+{
+ int err;
+
+ might_sleep();
+
+ if (!i915_active_acquire_if_busy(ref))
+ return 0;
+
+ /* Any fence added after the wait begins will not be auto-signaled */
+ err = flush_lazy_signals(ref);
i915_active_release(ref);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index ef572a0c2566..067e30b8927f 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -201,11 +201,57 @@ static int live_active_retire(void *arg)
return err;
}
+static int live_active_barrier(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct live_active *active;
+ int err = 0;
+
+ /* Check that we get a callback when requests retire upon waiting */
+
+ active = __live_alloc(i915);
+ if (!active)
+ return -ENOMEM;
+
+ err = i915_active_acquire(>base);
+ if (err)
+ goto out;
+
+ for_each_uabi_engine(engine, i915) {
+ err = i915_active_acquire_preallocate_barrier(>base,
+ engine);
+ if (err)
+ break;
+
+ i915_active_acquire_barrier(>base);
+ }
+
+ i915_active_release(>base);
+
+ if (err == 0)
+ err = i915_active_wait(>base);
+
+ if (err == 0 && !READ_ONCE(active->retired)) {
+ pr_err("i915_active not retired after flushing barriers!\n");
+ err = -EINVAL;
+ }
+
+out:
+ __live_put(active);
+
+ if (igt_flush_test(i915))
+ err = -EIO;
+
+ return err;
+}
+
int i915_active_live_selftests(struct drm_i915_private *i915)
{
static const struct i915_subtest tests[] = {
SUBTEST(live_active_wait),
SUBTEST(live_active_retire),
+ SUBTEST(live_active_barrier),
};
if (intel_gt_is_wedged(>gt))
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915: Flush idle barriers when waiting
Quoting Tvrtko Ursulin (2020-02-25 19:07:43)
>
> On 24/02/2020 09:59, Chris Wilson wrote:
> > -int i915_active_wait(struct i915_active *ref)
> > +static int flush_barrier(struct active_node *it)
> > {
> > - struct active_node *it, *n;
> > - int err = 0;
> > + struct intel_engine_cs *engine;
> >
> > - might_sleep();
> > + if (!is_barrier(>base))
> > + return 0;
> >
> > - if (!i915_active_acquire_if_busy(ref))
> > + engine = __barrier_to_engine(it);
> > + smp_rmb(); /* serialise with add_active_barriers */
> > + if (!is_barrier(>base))
> > return 0;
>
> What is the purpose of the first !is_barrier check? Just to kind of look
> better by not calling __bariier_to_engine on the wrong thing?
Yeah, and that smp_rmb() is on the expensive side (enough to justify a
branch). If I was confident I would mark up that first !is_barrier() with
likely(). Hmm, does the kernel still have the infrastructure to warn
those annotations are wrong?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915: Flush idle barriers when waiting
On 24/02/2020 09:59, Chris Wilson wrote:
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
Cc: Steve Carbonari
---
drivers/gpu/drm/i915/i915_active.c | 42 ++
drivers/gpu/drm/i915/selftests/i915_active.c | 46
2 files changed, 79 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 9ccb931a733e..fae7e3820592 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -7,6 +7,7 @@
#include
#include "gt/intel_context.h"
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_ring.h"
@@ -460,26 +461,49 @@ static void enable_signaling(struct i915_active_fence *active)
dma_fence_put(fence);
}
-int i915_active_wait(struct i915_active *ref)
+static int flush_barrier(struct active_node *it)
{
- struct active_node *it, *n;
- int err = 0;
+ struct intel_engine_cs *engine;
- might_sleep();
+ if (!is_barrier(>base))
+ return 0;
- if (!i915_active_acquire_if_busy(ref))
+ engine = __barrier_to_engine(it);
+ smp_rmb(); /* serialise with add_active_barriers */
+ if (!is_barrier(>base))
return 0;
What is the purpose of the first !is_barrier check? Just to kind of look
better by not calling __bariier_to_engine on the wrong thing?
- /* Flush lazy signals */
+ return intel_engine_flush_barriers(engine);
+}
+
+static int flush_lazy_signals(struct i915_active *ref)
+{
+ struct active_node *it, *n;
+ int err = 0;
+
enable_signaling(>excl);
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
- if (is_barrier(>base)) /* unconnected idle barrier */
- continue;
+ err = flush_barrier(it); /* unconnected idle barrier? */
+ if (err)
+ break;
enable_signaling(>base);
}
- /* Any fence added after the wait begins will not be auto-signaled */
+ return err;
+}
+
+int i915_active_wait(struct i915_active *ref)
+{
+ int err;
+
+ might_sleep();
+
+ if (!i915_active_acquire_if_busy(ref))
+ return 0;
+
+ /* Any fence added after the wait begins will not be auto-signaled */
+ err = flush_lazy_signals(ref);
i915_active_release(ref);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index ef572a0c2566..067e30b8927f 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -201,11 +201,57 @@ static int live_active_retire(void *arg)
return err;
}
+static int live_active_barrier(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct live_active *active;
+ int err = 0;
+
+ /* Check that we get a callback when requests retire upon waiting */
+
+ active = __live_alloc(i915);
+ if (!active)
+ return -ENOMEM;
+
+ err = i915_active_acquire(>base);
+ if (err)
+ goto out;
+
+ for_each_uabi_engine(engine, i915) {
+ err = i915_active_acquire_preallocate_barrier(>base,
+ engine);
+ if (err)
+ break;
+
+ i915_active_acquire_barrier(>base);
+ }
+
+ i915_active_release(>base);
+
+ if (err == 0)
+ err = i915_active_wait(>base);
+
+ if (err == 0 && !READ_ONCE(active->retired)) {
+ pr_err("i915_active not retired after flushing barriers!\n");
+ err = -EINVAL;
+ }
+
+out:
+ __live_put(active);
+
+ if (igt_flush_test(i915))
+ err = -EIO;
+
+ return err;
+}
+
int i915_active_live_selftests(struct drm_i915_private *i915)
{
static const struct i915_subtest tests[] = {
SUBTEST(live_active_wait),
SUBTEST(live_active_retire),
+ SUBTEST(live_active_barrier),
};
if (intel_gt_is_wedged(>gt))
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next
ported context runtime - Tvrtko - Update bug filling URL - Jani - Use async bind for PIN_USER into bsw/bxt ggtt - Chris - Use the kernel_context to measuer the breadcrumb size - Chris - Userptr fixes and robustness for big pages - Matt Auld - Various Display refactors and clean-ups, specially around logs and use of drm_i915_private - Jani, Ville - Various display refactors and fixes, especially around cdclk, modeset, and encoder - Chris, Jani - Various eDP/DP fixes around DPCD - Lyude - Various fixes and refactors for better Display watermark handling - Ville, Stanislav - Various other display refactors - Ville - Various refactor for better handling of display plane states - Ville - Wean off drm_pci_alloc/drm_pci_free - Chris - Correctly terminate connector iteration- Ville - Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt - Chris Thanks, Rodrigo. The following changes since commit 1b245ec5b685ebf8e6e5d1e6b5bcc03b6608e8b0: Merge tag 'drm-misc-next-2020-02-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-02-21 05:44:40 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-02-25 for you to fetch changes up to 53e3ca6749186b5c147964bddc4eb47ba8b5f69e: drm/i915: Update DRIVER_DATE to 20200225 (2020-02-25 10:41:22 -0800) - A backmerge of drm-next solving conflicts on i915/gt/intel_lrc.c - Clean up shadow batch after I915_EXEC_SECURE - Drop assertion that active->fence is unchanged Anshuman Gupta (1): drm/i915: HDCP support on above PORT_E Chris Wilson (119): drm/i915/pmu: Correct the rc6 offset upon enabling drm/i915/gt: Clear rc6 residency trackers across suspend drm/i915/gem: Take local vma references for the parser drm/i915/selftests: Add a mock i915_vma to the mock_ring drm/i915/gt: Use the BIT when checking the flags, not the index drm/i915/execlists: Leave resetting ring to intel_ring drm/i915/gt: Drop rogue space in the middle of GT_TRACE drm/i915: Keep track of request among the scheduling lists drm/i915/gt: Allow temporary suspension of inflight requests drm/i915/execlists: Offline error capture drm/i915: Include the debugfs params header for its own definition drm/i915: Fix typo in kerneldoc function name drm/i915: Satisfy smatch that a loop has at least one iteration drm/i915/gt: Report the currently active execlists request drm/i915/gt: Be paranoid and reset the GPU before release drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list drm/i915: Don't show the blank process name for internal/simulated errors drm/i915: Clear the GGTT_WRITE bit on unbinding the vma drm/i915/gt: Include a tell-tale for engine parking drm/i915/execlists: Take a reference while capturing the guilty request drm/i915/execlists: Reclaim the hanging virtual request drm/i915: Mark the removal of the i915_request from the sched.link drm/i915/gem: Convert vm idr to xarray drm/i915/gem: Detect overflow in calculating dumb buffer size drm/i915/selftests: Show the RC6 residency on parking failure drm/i915/gem: Prevent NULL pointer dereference on missing ctx->vm drm/i915: Check activity on i915_vma after confirming pin_count==0 drm/i915: Wait on vma activity before taking the mutex drm/i915/gt: Flush engine parking before release drm/i915/gt: Poison GTT scratch pages drm/i915/tgl: Re-enable RPS drm/i915/display: Squelch kerneldoc complaints drm/i915: Stub out i915_gpu_coredump_put drm/i915: Remove 'prefault_disable' modparam drm/i915: Tighten atomicity of i915_active_acquire vs i915_active_release drm/i915: Restore the kernel context after verifying the w/a drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex drm/i915: Skip capturing errors from internal contexts drm/i915/gt: Reorganise gen8+ interrupt handler drm/i915/gt: Tidy repetition in declaring gen8+ interrupts drm/i915/gt: Lift set-wedged engine dumping out of user paths drm/i915/trace: i915_request.prio is a signed value drm/i915/selftests: Lock the drm_mm as we search drm/i915/execlist: Mark up racy read of execlists->pending[0] drm/i915/gt: Hook up CS_MASTER_ERROR_INTERRUPT drm/i915/execlists: Ignore discrepancies in pending[] across resets drm/i915/gt: Skip global serialisation of clear_range for bxt vtd drm/i915/fbc: __intel_fbc_cleanup_cfb() may be called multiple times drm/i915/gem: Tighten checks and acquiring the mmap object drm/i915/gt: Rename i915_gem_restore_ggtt_mappings() for its new placement drm/i915: Use the async worker to avoid reclaim tainting the ggtt->mutex
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_persistence: Check precision of hostile cancellation
Quoting Tvrtko Ursulin (2020-02-25 18:18:12) > > On 25/02/2020 18:11, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2020-02-25 18:08:14) > >> > >> On 24/02/2020 21:56, Chris Wilson wrote: > >>> Check that if we have to remove a hostile request from a non-persistent > >>> context, we do so without harming any other concurrent users. > >>> > >>> Signed-off-by: Chris Wilson > >>> --- > >>> + /* All other spinners should be left unharmed */ > >>> + gem_quiescent_gpu(i915); > >>> + igt_assert_eq(sync_fence_wait(fence, reset_timeout_ms), 0); > >>> + igt_assert_eq(sync_fence_status(fence), 1); > >> > >> I don't quite get this test. Why would other spinners be unharmed? They > >> are non-preemptible as well. And non-persistent spinner is alone on the > >> engine. So what aspect you wanted to test? > > > > Per-engine reset. Termination of the non-persistent context should be > > clean and precise, we don't allow creation of non-persistent contexts > > unless we have that level of surgical precision. Otherwise it becomes a > > new attack vector. > > If it is just engine reset then it does what it says on the tin. I shall update the description to clarify that then :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_persistence: Check precision of hostile cancellation
On 25/02/2020 18:11, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-02-25 18:08:14) On 24/02/2020 21:56, Chris Wilson wrote: Check that if we have to remove a hostile request from a non-persistent context, we do so without harming any other concurrent users. Signed-off-by: Chris Wilson --- + /* All other spinners should be left unharmed */ + gem_quiescent_gpu(i915); + igt_assert_eq(sync_fence_wait(fence, reset_timeout_ms), 0); + igt_assert_eq(sync_fence_status(fence), 1); I don't quite get this test. Why would other spinners be unharmed? They are non-preemptible as well. And non-persistent spinner is alone on the engine. So what aspect you wanted to test? Per-engine reset. Termination of the non-persistent context should be clean and precise, we don't allow creation of non-persistent contexts unless we have that level of surgical precision. Otherwise it becomes a new attack vector. If it is just engine reset then it does what it says on the tin. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_persistence: Check precision of hostile cancellation
Quoting Tvrtko Ursulin (2020-02-25 18:08:14) > > On 24/02/2020 21:56, Chris Wilson wrote: > > Check that if we have to remove a hostile request from a non-persistent > > context, we do so without harming any other concurrent users. > > > > Signed-off-by: Chris Wilson > > --- > > + /* All other spinners should be left unharmed */ > > + gem_quiescent_gpu(i915); > > + igt_assert_eq(sync_fence_wait(fence, reset_timeout_ms), 0); > > + igt_assert_eq(sync_fence_status(fence), 1); > > I don't quite get this test. Why would other spinners be unharmed? They > are non-preemptible as well. And non-persistent spinner is alone on the > engine. So what aspect you wanted to test? Per-engine reset. Termination of the non-persistent context should be clean and precise, we don't allow creation of non-persistent contexts unless we have that level of surgical precision. Otherwise it becomes a new attack vector. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_persistence: Check precision of hostile cancellation
On 24/02/2020 21:56, Chris Wilson wrote:
Check that if we have to remove a hostile request from a non-persistent
context, we do so without harming any other concurrent users.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_persistence.c | 63
1 file changed, 63 insertions(+)
diff --git a/tests/i915/gem_ctx_persistence.c b/tests/i915/gem_ctx_persistence.c
index 20007f5c4..cd174d263 100644
--- a/tests/i915/gem_ctx_persistence.c
+++ b/tests/i915/gem_ctx_persistence.c
@@ -613,6 +613,62 @@ static void test_process_mixed(int pfd, unsigned int
engine)
gem_quiescent_gpu(pfd);
}
+static void
+test_saturated_hostile(int i915, const struct intel_execution_engine2 *engine)
+{
+ const struct intel_execution_engine2 *other;
+ igt_spin_t *spin;
+ uint32_t ctx;
+ int fence = -1;
+
+ /*
+* Check that if we have to remove a hostile request from a
+* non-persistent context, we do so without harming any other
+* concurrent users.
+*/
+
+ __for_each_physical_engine(i915, other) {
+ if (other->flags == engine->flags)
+ continue;
+
+ spin = igt_spin_new(i915,
+ .engine = other->flags,
+ .flags = (IGT_SPIN_NO_PREEMPTION |
+IGT_SPIN_FENCE_OUT));
+
+ if (fence < 0) {
+ fence = spin->out_fence;
+ } else {
+ int tmp;
+
+ tmp = sync_fence_merge(fence, spin->out_fence);
+ close(fence);
+ close(spin->out_fence);
+
+ fence = tmp;
+ }
+ spin->out_fence = -1;
+ }
+
+ ctx = gem_context_clone_with_engines(i915, 0);
+ gem_context_set_persistence(i915, ctx, false);
+ spin = igt_spin_new(i915, ctx,
+ .engine = engine->flags,
+ .flags = (IGT_SPIN_NO_PREEMPTION |
+ IGT_SPIN_POLL_RUN |
+ IGT_SPIN_FENCE_OUT));
+ igt_spin_busywait_until_started(spin);
+ gem_context_destroy(i915, ctx);
+
+ igt_assert_eq(sync_fence_wait(spin->out_fence, reset_timeout_ms), 0);
+ igt_assert_eq(sync_fence_status(spin->out_fence), -EIO);
+
+ /* All other spinners should be left unharmed */
+ gem_quiescent_gpu(i915);
+ igt_assert_eq(sync_fence_wait(fence, reset_timeout_ms), 0);
+ igt_assert_eq(sync_fence_status(fence), 1);
I don't quite get this test. Why would other spinners be unharmed? They
are non-preemptible as well. And non-persistent spinner is alone on the
engine. So what aspect you wanted to test?
Regards,
Tvrtko
+}
+
static void test_processes(int i915)
{
struct {
@@ -1041,6 +1097,13 @@ igt_main
}
}
+ igt_subtest_with_dynamic_f("saturated-hostile") {
+ __for_each_physical_engine(i915, e) {
+ igt_dynamic_f("%s", e->name)
+ test_saturated_hostile(i915, e);
+ }
+ }
+
igt_subtest("smoketest")
smoketest(i915);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/i915/selftests: Check recovery from corrupted LRC
On Tue, 25 Feb 2020 at 08:22, Chris Wilson wrote: > > Check that we can recover if the LRC is totally corrupted. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ 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: stop assigning drm->dev_private pointer
== Series Details == Series: drm/i915: stop assigning drm->dev_private pointer URL : https://patchwork.freedesktop.org/series/73848/ State : success == Summary == CI Bug Log - changes from CI_DRM_7996_full -> Patchwork_16685_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16685_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +7 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@deep-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112146]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-iclb8/igt@gem_exec_sched...@deep-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-iclb1/igt@gem_exec_sched...@deep-bsd.html * igt@gem_exec_schedule@pi-common-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +20 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd1.html * igt@i915_pm_rps@reset: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#413]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-iclb5/igt@i915_pm_...@reset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-iclb5/igt@i915_pm_...@reset.html * igt@i915_suspend@debugfs-reader: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-skl1/igt@i915_susp...@debugfs-reader.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-skl9/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#72]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#221]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-skl9/igt@kms_f...@flip-vs-suspend-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-skl7/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +7 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-kbl1/igt@kms_frontbuffer_track...@fbc-suspend.html - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-apl3/igt@kms_frontbuffer_track...@fbc-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-apl6/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([IGT#6]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-skl9/igt@kms_plane_multi...@atomic-pipe-a-tiling-y.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-skl8/igt@kms_plane_multi...@atomic-pipe-a-tiling-y.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-iclb1/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_psr@psr2_cursor_render: - shard-tglb: [PASS][23] -> [SKIP][24] ([i915#668]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-tglb6/igt@kms_psr@psr2_cursor_render.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16685/shard-tglb2/igt@kms_psr@psr2_cursor_render.html Possible fixes * igt@gem_busy@busy-vcs1: - shard-iclb: [SKIP][25] ([fdo#112080]) -> [PASS][26] +17 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7996/shard-iclb5/igt@gem_b...@busy-vcs1.html [26]:
Re: [Intel-gfx] [PATCH v2 20/20] drm/i915: Check slice mask for holes
On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make sure the dbuf slice mask for any individual pipe has no
> holes between the slices.
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 7edac506d343..fa39ab0b1223 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3827,6 +3827,14 @@ static int intel_dbuf_slice_size(struct
> drm_i915_private *dev_priv)
> INTEL_INFO(dev_priv)->num_supported_dbuf_slices;
> }
>
> +static bool bitmask_is_contiguous(unsigned int bitmask)
> +{
> + if (bitmask)
> + bitmask >>= ffs(bitmask) - 1;
> +
> + return is_power_of_2(bitmask + 1);
> +}
> +
Well, I guess we just don't trust BSpec tables here :)
Shouldn't this be already taken care of by the actual tables, which we
anyway seem have to encode "as is".
Moreover, I wouldn't even be sure that one day, they won't come up
with that you can have gaps for those, anyway currently
we don't have them according to current tables
Stan
> static void
> skl_ddb_entry_for_slices(struct drm_i915_private *dev_priv, u8
> slice_mask,
>struct skl_ddb_entry *ddb)
> @@ -3844,6 +3852,7 @@ skl_ddb_entry_for_slices(struct
> drm_i915_private *dev_priv, u8 slice_mask,
>
> WARN_ON(ddb->start >= ddb->end);
> WARN_ON(ddb->end > intel_dbuf_size(dev_priv));
> + WARN_ON(!bitmask_is_contiguous(slice_mask));
> }
>
> static unsigned int intel_crtc_ddb_weight(const struct
> intel_crtc_state *crtc_state)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/20] drm/i915: Introduce proper dbuf state
On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a global state to track the dbuf slices. Gets rid of all the
> nasty
> coupling between state->modeset and dbuf recomputation. Also we can
> now
> totally nuke state->active_pipe_changes.
>
> dev_priv->wm.distrust_bios_wm still remains, but that too will get
> nuked soon.
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 67 +--
> .../drm/i915/display/intel_display_power.c| 8 +-
> .../drm/i915/display/intel_display_types.h| 13 --
> drivers/gpu/drm/i915/i915_drv.h | 11 +-
> drivers/gpu/drm/i915/intel_pm.c | 189 --
>
> drivers/gpu/drm/i915/intel_pm.h | 22 ++
> 6 files changed, 209 insertions(+), 101 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6952c398cc43..659b952c8e2f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7581,6 +7581,8 @@ static void intel_crtc_disable_noatomic(struct
> intel_crtc *crtc,
> to_intel_bw_state(dev_priv->bw_obj.state);
> struct intel_cdclk_state *cdclk_state =
> to_intel_cdclk_state(dev_priv->cdclk.obj.state);
> + struct intel_dbuf_state *dbuf_state =
> + to_intel_dbuf_state(dev_priv->dbuf.obj.state);
> struct intel_crtc_state *crtc_state =
> to_intel_crtc_state(crtc->base.state);
> enum intel_display_power_domain domain;
> @@ -7654,6 +7656,8 @@ static void intel_crtc_disable_noatomic(struct
> intel_crtc *crtc,
> cdclk_state->min_voltage_level[pipe] = 0;
> cdclk_state->active_pipes &= ~BIT(pipe);
>
> + dbuf_state->active_pipes &= ~BIT(pipe);
> +
Still would vote to encapsulate active_pipes to some other state, which
would be then used by both CDCLK and DBUF states, so that we don't
duplicate same field in semantically different states and thus increase
probability of forgetting to assign it somethere, like we had an issue
with "active_pipe_changes" which would be now eliminated.
Could it be like global_crtc_state->active_pipes? Probably name is
not the best here, just to reflect the idea.
Would be cool to have all subsystems encapsulated into those global
objects, while each is responsible for it's own area.
Stan
> bw_state->data_rate[pipe] = 0;
> bw_state->num_active_planes[pipe] = 0;
> }
> @@ -13991,10 +13995,10 @@ static void verify_wm_state(struct
> intel_crtc *crtc,
> hw_enabled_slices = intel_enabled_dbuf_slices_mask(dev_priv);
>
> if (INTEL_GEN(dev_priv) >= 11 &&
> - hw_enabled_slices != dev_priv->enabled_dbuf_slices_mask)
> + hw_enabled_slices != dev_priv->dbuf.enabled_slices)
> drm_err(_priv->drm,
> "mismatch in DBUF Slices (expected 0x%x, got
> 0x%x)\n",
> - dev_priv->enabled_dbuf_slices_mask,
> + dev_priv->dbuf.enabled_slices,
> hw_enabled_slices);
>
> /* planes */
> @@ -14529,9 +14533,7 @@ static int intel_modeset_checks(struct
> intel_atomic_state *state)
> state->modeset = true;
> state->active_pipes = intel_calc_active_pipes(state, dev_priv-
> >active_pipes);
>
> - state->active_pipe_changes = state->active_pipes ^ dev_priv-
> >active_pipes;
> -
> - if (state->active_pipe_changes) {
> + if (state->active_pipes != dev_priv->active_pipes) {
> ret = _intel_atomic_lock_global_state(state);
> if (ret)
> return ret;
> @@ -15292,22 +15294,38 @@ static void
> intel_update_trans_port_sync_crtcs(struct intel_crtc *crtc,
> static void icl_dbuf_slice_pre_update(struct intel_atomic_state
> *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask;
> - u8 required_slices = state->enabled_dbuf_slices_mask;
> - u8 slices_union = hw_enabled_slices | required_slices;
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
>
> - if (INTEL_GEN(dev_priv) >= 11 && slices_union !=
> hw_enabled_slices)
> - gen9_dbuf_slices_update(dev_priv, slices_union);
> + if (!new_dbuf_state ||
> + new_dbuf_state->enabled_slices == old_dbuf_state-
> >enabled_slices)
> + return;
> +
> + WARN_ON(!new_dbuf_state->base.changed);
> +
> + gen9_dbuf_slices_update(dev_priv,
> + old_dbuf_state->enabled_slices |
> + new_dbuf_state->enabled_slices);
> }
>
> static void icl_dbuf_slice_post_update(struct intel_atomic_state
> *state)
>
Re: [Intel-gfx] [PATCH v2 05/20] drm/i915: Make skl_compute_dbuf_slices() behave consistently for all platforms
On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently skl_compute_dbuf_slices() returns 0 for any inactive pipe > on > icl+, but returns BIT(S1) on pre-icl for any pipe (whether it's > active or > not). Let's make the behaviour consistent and always return 0 for any > inactive pipe. > > Cc: Stanislav Lisovskiy > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_pm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index a2e78969c0df..640f4c4fd508 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4408,7 +4408,7 @@ static u8 skl_compute_dbuf_slices(const struct > intel_crtc_state *crtc_state, >* For anything else just return one slice yet. >* Should be extended for other platforms. >*/ > - return BIT(DBUF_S1); > + return active_pipes & BIT(pipe) ? BIT(DBUF_S1) : 0; I think the initial idea was this won't be even called if there are no active pipes at all - skl_ddb_get_pipe_allocation_limits would bail out immediately. If there were some active pipes - then we will have to use slice S1 anyway - because there were simply no other slices available. If some pipes were inactive - they are currently skipped by !crtc_state->hw.active check - so I would just keep it simple and don't call this function for non-active pipes at all. Currently we are just ORing slice bitmasks only from active pipes. Stan > } > > static u64 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
On Mon, Feb 24, 2020 at 07:46:59PM +0100, Christian König wrote:
> Am 23.02.20 um 17:54 schrieb Thomas Hellström (VMware):
> > On 2/23/20 4:45 PM, Christian König wrote:
> > > Am 21.02.20 um 18:12 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > Yeah the Great Plan (tm) is to fully rely on ww_mutex slowly
> > > > degenerating
> > > > into essentially a global lock. But only when there's actual contention
> > > > and thrashing.
> > >
> > > Yes exactly. A really big problem in TTM is currently that we drop
> > > the lock after evicting BOs because they tend to move in again
> > > directly after that.
> > >
> > > From practice I can also confirm that there is exactly zero benefit
> > > from dropping locks early and reacquire them for example for the VM
> > > page tables. That's just makes it more likely that somebody needs to
> > > roll back and this is what we need to avoid in the first place.
> >
> > If you have a benchmarking setup available it would be very interesting
> > for future reference to see how changing from WD to WW mutexes affects
> > the roll back frequency. WW is known to cause rollbacks much less
> > frequently but there is more work associated with each rollback.
>
> Not of hand. To be honest I still have a hard time to get a grip on the
> difference between WD and WW from the algorithm point of view. So I can't
> judge that difference at all.
>
> > > Contention on BO locks during command submission is perfectly fine
> > > as long as this is as lightweight as possible while we don't have
> > > trashing. When we have trashing multi submission performance is best
> > > archived to just favor a single process to finish its business and
> > > block everybody else.
> >
> > Hmm. Sounds like we need a per-manager ww_rwsem protecting manager
> > allocation, taken in write-mode then there's thrashing. In read-mode
> > otherwise. That would limit the amount of "unnecessary" locks we'd have
> > to keep and reduce unwanted side-effects, (see below):
>
> Well per-manager (you mean per domain here don't you?) doesn't sound like
> that useful because we rarely use only one domain, but I'm actually
> questioning for quite a while if the per BO lock scheme was the right
> approach.
>
> See from the performance aspect the closest to ideal solution I can think of
> would be a ww_rwsem per user of a resource.
>
> In other words we don't lock BOs, but instead a list of all their users and
> when you want to evict a BO you need to walk that list and inform all users
> that the BO will be moving.
>
> During command submission you then have the fast path which rather just
> grabs the read side of the user lock and check if all BOs are still in the
> expected place.
>
> If some BOs were evicted you back off and start the slow path, e.g. maybe
> even copy additional data from userspace then grab the write side of the
> lock etc.. etc...
>
> That approach is similar to what we use in amdgpu with the per-VM BOs, but
> goes a step further. Problem is that we are so used to per BO locks in the
> kernel that this is probably not doable any more.
Yeah I think it'd be nice to have the same approach for shared bo too. I
guess what we could do is something like this (spinning your ww_rwmutex
idea a bit further):
dma_buf_read_lock(buf, vm)
{
if (enabled(CONFIG_DEBUG_WW_MUTEX_SLOWPATH))
{
check that vm is indeed listed in buf and splat if not
}
/* for a buf that's not shared in multiple vm we'd have buf->resv
* == vm->resv here */
return ww_mutex_lock(vm->resv);
}
dma_buf_write_lock(buf)
{
for_each_vm_in_buf(buf, vm) {
ww_mutex_lock(vm->resv);
}
}
Ideally we'd track all these vms with something slightly less shoddy than
a linked list :-) Resizeable array is probably pretty good, I think we
only ever need to go from buf -> vm list, not the other way round. At
least in dma_resv/dma_buf code, driver code ofc needs to keep a list of
all bo bound to a vm somewhere. But that's probably a much bigger
datastructure for tracking vma offsets and mappings and other things on
top.
Ofc to even just get there we'd need something like the sublock list to
keep track of all the additional locks we'd need for the writer lock. And
we'd need the release callback for backoff, so that we could also go
through the slowpath on a vm object that we're not holding a full
reference on. That also means vm need to be refcounted.
And the list of vms on a buffer need to be protected with some lock and
the usual kref_get_unless_zero trickery.
But with all this I think we can make the dma_buf_write_lock lock 100%
like the old per-buffer lock for everyone. And execbuf could switch over
to dma_buf_read_lock for shared buffers. Bonus points when the gpu context
just keeps track of a list of shared vm used by buffers in that context
...
That way we could make vm fastpath locking a la amdgpu opt-in, while
keeping everyone else on the per-object
[Intel-gfx] [PATCH v2 12/20] drm/i915: Extract intel_crtc_ddb_weight()
From: Ville Syrjälä
skl_ddb_get_pipe_allocation_limits() doesn't care how the weights
for distributing the ddb are caclculated for each pipe. Put that
calculation into a separate function so that such mundane details
are hidden from view.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 46 -
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d2edfb820dd9..3f48ce7517e2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3842,6 +3842,25 @@ static u16 intel_get_ddb_size(struct drm_i915_private
*dev_priv)
return ddb_size;
}
+static unsigned int intel_crtc_ddb_weight(const struct intel_crtc_state
*crtc_state)
+{
+ const struct drm_display_mode *adjusted_mode =
+ _state->hw.adjusted_mode;
+ int hdisplay, vdisplay;
+
+ if (!crtc_state->hw.active)
+ return 0;
+
+ /*
+* Watermark/ddb requirement highly depends upon width of the
+* framebuffer, So instead of allocating DDB equally among pipes
+* distribute DDB based on resolution/width of the display.
+*/
+ drm_mode_get_hv_timing(adjusted_mode, , );
+
+ return hdisplay;
+}
+
static u8 skl_compute_dbuf_slices(const struct intel_crtc_state *crtc_state,
u8 active_pipes);
@@ -3856,7 +3875,7 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_crtc *for_crtc = crtc_state->uapi.crtc;
const struct intel_crtc *crtc;
- u32 pipe_width = 0, total_width_in_range = 0,
width_before_pipe_in_range = 0;
+ unsigned int pipe_weight = 0, total_weight = 0, weight_before_pipe = 0;
enum pipe for_pipe = to_intel_crtc(for_crtc)->pipe;
struct intel_dbuf_state *new_dbuf_state =
intel_atomic_get_new_dbuf_state(intel_state);
@@ -3925,18 +3944,11 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
*/
ddb_range_size = hweight8(dbuf_slice_mask) * slice_size;
- /*
-* Watermark/ddb requirement highly depends upon width of the
-* framebuffer, So instead of allocating DDB equally among pipes
-* distribute DDB based on resolution/width of the display.
-*/
total_slice_mask = dbuf_slice_mask;
for_each_new_intel_crtc_in_state(intel_state, crtc, crtc_state, i) {
- const struct drm_display_mode *adjusted_mode =
- _state->hw.adjusted_mode;
enum pipe pipe = crtc->pipe;
- int hdisplay, vdisplay;
- u32 pipe_dbuf_slice_mask;
+ unsigned int weight;
+ u8 pipe_dbuf_slice_mask;
if (!crtc_state->hw.active)
continue;
@@ -3963,14 +3975,13 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
if (dbuf_slice_mask != pipe_dbuf_slice_mask)
continue;
- drm_mode_get_hv_timing(adjusted_mode, , );
-
- total_width_in_range += hdisplay;
+ weight = intel_crtc_ddb_weight(crtc_state);
+ total_weight += weight;
if (pipe < for_pipe)
- width_before_pipe_in_range += hdisplay;
+ weight_before_pipe += weight;
else if (pipe == for_pipe)
- pipe_width = hdisplay;
+ pipe_weight = weight;
}
/*
@@ -3985,9 +3996,8 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
return ret;
}
- start = ddb_range_size * width_before_pipe_in_range /
total_width_in_range;
- end = ddb_range_size *
- (width_before_pipe_in_range + pipe_width) /
total_width_in_range;
+ start = ddb_range_size * weight_before_pipe / total_weight;
+ end = ddb_range_size * (weight_before_pipe + pipe_weight) /
total_weight;
alloc->start = offset + start;
alloc->end = offset + end;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/20] drm/i915: Handle some leftover s/intel_crtc/crtc/
From: Ville Syrjälä
Switch to the preferred 'crtc' name for our crtc variables.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 22aa205793e5..543634d3e10c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2776,7 +2776,7 @@ static bool ilk_validate_wm_level(int level,
}
static void ilk_compute_wm_level(const struct drm_i915_private *dev_priv,
-const struct intel_crtc *intel_crtc,
+const struct intel_crtc *crtc,
int level,
struct intel_crtc_state *crtc_state,
const struct intel_plane_state *pristate,
@@ -3107,7 +3107,7 @@ static bool ilk_validate_pipe_wm(const struct
drm_i915_private *dev_priv,
static int ilk_compute_pipe_wm(struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct intel_pipe_wm *pipe_wm;
struct intel_plane *plane;
const struct intel_plane_state *plane_state;
@@ -3147,7 +3147,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state
*crtc_state)
usable_level = 0;
memset(_wm->wm, 0, sizeof(pipe_wm->wm));
- ilk_compute_wm_level(dev_priv, intel_crtc, 0, crtc_state,
+ ilk_compute_wm_level(dev_priv, crtc, 0, crtc_state,
pristate, sprstate, curstate, _wm->wm[0]);
if (!ilk_validate_pipe_wm(dev_priv, pipe_wm))
@@ -3158,7 +3158,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state
*crtc_state)
for (level = 1; level <= usable_level; level++) {
struct intel_wm_level *wm = _wm->wm[level];
- ilk_compute_wm_level(dev_priv, intel_crtc, level, crtc_state,
+ ilk_compute_wm_level(dev_priv, crtc, level, crtc_state,
pristate, sprstate, curstate, wm);
/*
@@ -4549,9 +4549,8 @@ static int
skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
{
struct drm_atomic_state *state = crtc_state->uapi.state;
- struct drm_crtc *crtc = crtc_state->uapi.crtc;
- struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct skl_ddb_entry *alloc = _state->wm.skl.ddb;
u16 alloc_size, start = 0;
u16 total[I915_MAX_PLANES] = {};
@@ -4609,7 +4608,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
*/
for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
blocks = 0;
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ for_each_plane_id_on_crtc(crtc, plane_id) {
const struct skl_plane_wm *wm =
_state->wm.skl.optimal.planes[plane_id];
@@ -4646,7 +4645,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
* watermark level, plus an extra share of the leftover blocks
* proportional to its relative data rate.
*/
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ for_each_plane_id_on_crtc(crtc, plane_id) {
const struct skl_plane_wm *wm =
_state->wm.skl.optimal.planes[plane_id];
u64 rate;
@@ -4685,7 +4684,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
/* Set the actual DDB start/end points for each plane */
start = alloc->start;
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ for_each_plane_id_on_crtc(crtc, plane_id) {
struct skl_ddb_entry *plane_alloc =
_state->wm.skl.plane_ddb_y[plane_id];
struct skl_ddb_entry *uv_plane_alloc =
@@ -4719,7 +4718,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
* that aren't actually possible.
*/
for (level++; level <= ilk_wm_max_level(dev_priv); level++) {
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+ for_each_plane_id_on_crtc(crtc, plane_id) {
struct skl_plane_wm *wm =
_state->wm.skl.optimal.planes[plane_id];
@@ -4756,7 +4755,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
* Go back and disable the transition watermark if it turns out we
* don't have enough DDB blocks for it.
*/
-
[Intel-gfx] [PATCH v2 05/20] drm/i915: Make skl_compute_dbuf_slices() behave consistently for all platforms
From: Ville Syrjälä Currently skl_compute_dbuf_slices() returns 0 for any inactive pipe on icl+, but returns BIT(S1) on pre-icl for any pipe (whether it's active or not). Let's make the behaviour consistent and always return 0 for any inactive pipe. Cc: Stanislav Lisovskiy Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index a2e78969c0df..640f4c4fd508 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4408,7 +4408,7 @@ static u8 skl_compute_dbuf_slices(const struct intel_crtc_state *crtc_state, * For anything else just return one slice yet. * Should be extended for other platforms. */ - return BIT(DBUF_S1); + return active_pipes & BIT(pipe) ? BIT(DBUF_S1) : 0; } static u64 -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 19/20] drm/i915: Do a bit more initial readout for dbuf
From: Ville Syrjälä
Readout the dbuf related stuff during driver init/resume and
stick it into our dbuf state.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 --
drivers/gpu/drm/i915/intel_pm.c | 48 +++-
2 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e3df43f3932d..21ad1adcc1eb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17475,14 +17475,10 @@ void intel_modeset_init_hw(struct drm_i915_private
*i915)
{
struct intel_cdclk_state *cdclk_state =
to_intel_cdclk_state(i915->cdclk.obj.state);
- struct intel_dbuf_state *dbuf_state =
- to_intel_dbuf_state(i915->dbuf.obj.state);
intel_update_cdclk(i915);
intel_dump_cdclk_config(>cdclk.hw, "Current CDCLK");
cdclk_state->logical = cdclk_state->actual = i915->cdclk.hw;
-
- dbuf_state->enabled_slices = i915->dbuf.enabled_slices;
}
static int sanitize_watermarks_add_affected(struct drm_atomic_state *state)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c11508fb3fac..7edac506d343 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5363,6 +5363,18 @@ static inline bool skl_ddb_entries_overlap(const struct
skl_ddb_entry *a,
return a->start < b->end && b->start < a->end;
}
+static void skl_ddb_entry_union(struct skl_ddb_entry *a,
+ const struct skl_ddb_entry *b)
+{
+ if (a->end && b->end) {
+ a->start = min(a->start, b->start);
+ a->end = max(a->end, b->end);
+ } else if (b->end) {
+ a->start = b->start;
+ a->end = b->end;
+ }
+}
+
bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry *ddb,
const struct skl_ddb_entry *entries,
int num_entries, int ignore_idx)
@@ -5857,14 +5869,46 @@ void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc,
void skl_wm_get_hw_state(struct drm_i915_private *dev_priv)
{
+ struct intel_dbuf_state *dbuf_state =
+ to_intel_dbuf_state(dev_priv->dbuf.obj.state);
struct intel_crtc *crtc;
- struct intel_crtc_state *crtc_state;
for_each_intel_crtc(_priv->drm, crtc) {
- crtc_state = to_intel_crtc_state(crtc->base.state);
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
+ enum pipe pipe = crtc->pipe;
+ enum plane_id plane_id;
skl_pipe_wm_get_hw_state(crtc, _state->wm.skl.optimal);
+
+ memset(_state->ddb[pipe], 0,
sizeof(dbuf_state->ddb[pipe]));
+
+ for_each_plane_id_on_crtc(crtc, plane_id) {
+ struct skl_ddb_entry *ddb_y =
+ _state->wm.skl.plane_ddb_y[plane_id];
+ struct skl_ddb_entry *ddb_uv =
+ _state->wm.skl.plane_ddb_uv[plane_id];
+
+ skl_ddb_get_hw_plane_state(dev_priv, crtc->pipe,
+ plane_id, ddb_y, ddb_uv);
+
+ skl_ddb_entry_union(_state->ddb[pipe], ddb_y);
+ skl_ddb_entry_union(_state->ddb[pipe], ddb_uv);
+ }
+
+ dbuf_state->slices[pipe] =
+ skl_compute_dbuf_slices(crtc, dbuf_state->active_pipes);
+
+ dbuf_state->weight[pipe] = intel_crtc_ddb_weight(crtc_state);
+
+ drm_dbg_kms(_priv->drm,
+ "[CRTC:%d:%s] dbuf slices 0x%x, ddb (%d - %d),
active pipes 0x%x\n",
+ crtc->base.base.id, crtc->base.name,
+ dbuf_state->slices[pipe],
dbuf_state->ddb[pipe].start,
+ dbuf_state->ddb[pipe].end,
dbuf_state->active_pipes);
}
+
+ dbuf_state->enabled_slices = dev_priv->dbuf.enabled_slices;
}
static void ilk_pipe_wm_get_hw_state(struct intel_crtc *crtc)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/20] drm/i915: Unify the low level dbuf code
From: Ville Syrjälä
The low level dbuf slice code is rather inconsitent with its
functiona naming and organization. Make it more consistent.
Also share the enable/disable functions between all platforms
since the same code works just fine for all of them.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +--
.../drm/i915/display/intel_display_power.c| 44 ---
.../drm/i915/display/intel_display_power.h| 6 +--
3 files changed, 24 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3031e64ee518..6952c398cc43 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15296,9 +15296,8 @@ static void icl_dbuf_slice_pre_update(struct
intel_atomic_state *state)
u8 required_slices = state->enabled_dbuf_slices_mask;
u8 slices_union = hw_enabled_slices | required_slices;
- /* If 2nd DBuf slice required, enable it here */
if (INTEL_GEN(dev_priv) >= 11 && slices_union != hw_enabled_slices)
- icl_dbuf_slices_update(dev_priv, slices_union);
+ gen9_dbuf_slices_update(dev_priv, slices_union);
}
static void icl_dbuf_slice_post_update(struct intel_atomic_state *state)
@@ -15307,9 +15306,8 @@ static void icl_dbuf_slice_post_update(struct
intel_atomic_state *state)
u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask;
u8 required_slices = state->enabled_dbuf_slices_mask;
- /* If 2nd DBuf slice is no more required disable it */
if (INTEL_GEN(dev_priv) >= 11 && required_slices != hw_enabled_slices)
- icl_dbuf_slices_update(dev_priv, required_slices);
+ gen9_dbuf_slices_update(dev_priv, required_slices);
}
static void skl_commit_modeset_enables(struct intel_atomic_state *state)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index e81e561e8ac0..ce3bbc4c7a27 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4433,15 +4433,18 @@ static void intel_power_domains_sync_hw(struct
drm_i915_private *dev_priv)
mutex_unlock(_domains->lock);
}
-static void intel_dbuf_slice_set(struct drm_i915_private *dev_priv,
-enum dbuf_slice slice, bool enable)
+static void gen9_dbuf_slice_set(struct drm_i915_private *dev_priv,
+ enum dbuf_slice slice, bool enable)
{
i915_reg_t reg = DBUF_CTL_S(slice);
bool state;
u32 val;
val = intel_de_read(dev_priv, reg);
- val = enable ? (val | DBUF_POWER_REQUEST) : (val & ~DBUF_POWER_REQUEST);
+ if (enable)
+ val |= DBUF_POWER_REQUEST;
+ else
+ val &= ~DBUF_POWER_REQUEST;
intel_de_write(dev_priv, reg, val);
intel_de_posting_read(dev_priv, reg);
udelay(10);
@@ -4452,18 +4455,8 @@ static void intel_dbuf_slice_set(struct drm_i915_private
*dev_priv,
slice, enable ? "enable" : "disable");
}
-static void gen9_dbuf_enable(struct drm_i915_private *dev_priv)
-{
- icl_dbuf_slices_update(dev_priv, BIT(DBUF_S1));
-}
-
-static void gen9_dbuf_disable(struct drm_i915_private *dev_priv)
-{
- icl_dbuf_slices_update(dev_priv, 0);
-}
-
-void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
- u8 req_slices)
+void gen9_dbuf_slices_update(struct drm_i915_private *dev_priv,
+u8 req_slices)
{
int num_slices = INTEL_INFO(dev_priv)->num_supported_dbuf_slices;
struct i915_power_domains *power_domains = _priv->power_domains;
@@ -4486,28 +4479,29 @@ void icl_dbuf_slices_update(struct drm_i915_private
*dev_priv,
mutex_lock(_domains->lock);
for (slice = DBUF_S1; slice < num_slices; slice++)
- intel_dbuf_slice_set(dev_priv, slice,
-req_slices & BIT(slice));
+ gen9_dbuf_slice_set(dev_priv, slice, req_slices & BIT(slice));
dev_priv->enabled_dbuf_slices_mask = req_slices;
mutex_unlock(_domains->lock);
}
-static void icl_dbuf_enable(struct drm_i915_private *dev_priv)
+static void gen9_dbuf_enable(struct drm_i915_private *dev_priv)
{
- skl_ddb_get_hw_state(dev_priv);
+ dev_priv->enabled_dbuf_slices_mask =
+ intel_enabled_dbuf_slices_mask(dev_priv);
+
/*
* Just power up at least 1 slice, we will
* figure out later which slices we have and what we need.
*/
- icl_dbuf_slices_update(dev_priv, dev_priv->enabled_dbuf_slices_mask |
- BIT(DBUF_S1));
+ gen9_dbuf_slices_update(dev_priv, BIT(DBUF_S1) |
+
[Intel-gfx] [PATCH v2 20/20] drm/i915: Check slice mask for holes
From: Ville Syrjälä
Make sure the dbuf slice mask for any individual pipe has no
holes between the slices.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7edac506d343..fa39ab0b1223 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3827,6 +3827,14 @@ static int intel_dbuf_slice_size(struct drm_i915_private
*dev_priv)
INTEL_INFO(dev_priv)->num_supported_dbuf_slices;
}
+static bool bitmask_is_contiguous(unsigned int bitmask)
+{
+ if (bitmask)
+ bitmask >>= ffs(bitmask) - 1;
+
+ return is_power_of_2(bitmask + 1);
+}
+
static void
skl_ddb_entry_for_slices(struct drm_i915_private *dev_priv, u8 slice_mask,
struct skl_ddb_entry *ddb)
@@ -3844,6 +3852,7 @@ skl_ddb_entry_for_slices(struct drm_i915_private
*dev_priv, u8 slice_mask,
WARN_ON(ddb->start >= ddb->end);
WARN_ON(ddb->end > intel_dbuf_size(dev_priv));
+ WARN_ON(!bitmask_is_contiguous(slice_mask));
}
static unsigned int intel_crtc_ddb_weight(const struct intel_crtc_state
*crtc_state)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/20] drm/i915: Proper dbuf global state
From: Ville Syrjälä More complete version of intel_dbuf_state. We finally get rid of distrust_bios_wm and all the uglyness surrounding it. And we no longer have to know ahead of time whether the duf allocation might change or not, and thus don't need to pull in all crtcs into the state up front. Now we just compute the new dbuf state, and if it changes the affected crtcs get added to the state naturally. + a bunch of cleanups. Entire series available here: git://github.com/vsyrjala/linux.git dbuf_state_2 Cc: Stanislav Lisovskiy Ville Syrjälä (20): drm/i915: Handle some leftover s/intel_crtc/crtc/ drm/i915: Remove garbage WARNs drm/i915: Add missing commas to dbuf tables drm/i915: Use a sentinel to terminate the dbuf slice arrays drm/i915: Make skl_compute_dbuf_slices() behave consistently for all platforms drm/i915: Polish some dbuf debugs drm/i915: Unify the low level dbuf code drm/i915: Introduce proper dbuf state drm/i915: Nuke skl_ddb_get_hw_state() drm/i915: Move the dbuf pre/post plane update drm/i915: Clean up dbuf debugs during .atomic_check() drm/i915: Extract intel_crtc_ddb_weight() drm/i915: Pass the crtc to skl_compute_dbuf_slices() drm/i915: Introduce intel_dbuf_slice_size() drm/i915: Introduce skl_ddb_entry_for_slices() drm/i915: Move pipe ddb entries into the dbuf state drm/i915: Extract intel_crtc_dbuf_weights() drm/i915: Encapsulate dbuf state handling harder drm/i915: Do a bit more initial readout for dbuf drm/i915: Check slice mask for holes drivers/gpu/drm/i915/display/intel_display.c | 95 +-- .../drm/i915/display/intel_display_debugfs.c | 1 - .../drm/i915/display/intel_display_power.c| 80 +- .../drm/i915/display/intel_display_power.h| 6 +- .../drm/i915/display/intel_display_types.h| 14 - drivers/gpu/drm/i915/i915_drv.h | 16 +- drivers/gpu/drm/i915/intel_pm.c | 741 ++ drivers/gpu/drm/i915/intel_pm.h | 31 +- 8 files changed, 521 insertions(+), 463 deletions(-) -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 14/20] drm/i915: Introduce intel_dbuf_slice_size()
From: Ville Syrjälä
Put the code into a function with a descriptive name. Also relocate
the code a bit help future work.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 34 +++--
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 256622b603cd..9baf31e06011 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3809,6 +3809,24 @@ bool intel_can_enable_sagv(struct intel_atomic_state
*state)
return true;
}
+static int intel_dbuf_size(struct drm_i915_private *dev_priv)
+{
+ int ddb_size = INTEL_INFO(dev_priv)->ddb_size;
+
+ drm_WARN_ON(_priv->drm, ddb_size == 0);
+
+ if (INTEL_GEN(dev_priv) < 11)
+ return ddb_size - 4; /* 4 blocks for bypass path allocation */
+
+ return ddb_size;
+}
+
+static int intel_dbuf_slice_size(struct drm_i915_private *dev_priv)
+{
+ return intel_dbuf_size(dev_priv) /
+ INTEL_INFO(dev_priv)->num_supported_dbuf_slices;
+}
+
/*
* Calculate initial DBuf slice offset, based on slice size
* and mask(i.e if slice size is 1024 and second slice is enabled
@@ -3830,17 +3848,6 @@ icl_get_first_dbuf_slice_offset(u32 dbuf_slice_mask,
return offset;
}
-static u16 intel_get_ddb_size(struct drm_i915_private *dev_priv)
-{
- u16 ddb_size = INTEL_INFO(dev_priv)->ddb_size;
-
- drm_WARN_ON(_priv->drm, ddb_size == 0);
-
- if (INTEL_GEN(dev_priv) < 11)
- return ddb_size - 4; /* 4 blocks for bypass path allocation */
-
- return ddb_size;
-}
static unsigned int intel_crtc_ddb_weight(const struct intel_crtc_state
*crtc_state)
{
@@ -3900,9 +3907,8 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
return 0;
}
- ddb_size = intel_get_ddb_size(dev_priv);
-
- slice_size = ddb_size / INTEL_INFO(dev_priv)->num_supported_dbuf_slices;
+ ddb_size = intel_dbuf_size(dev_priv);
+ slice_size = intel_dbuf_slice_size(dev_priv);
/*
* If the state doesn't change the active CRTC's or there is no
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/20] drm/i915: Move the dbuf pre/post plane update
From: Ville Syrjälä
Encapsulate the dbuf state more by moving the pre/post
plane functions out from intel_display.c. We stick them
into intel_pm.c since that's where the rest of the code
lives for now.
Eventually we should add a new file for this stuff at which
point we also need to decide if it makes sense to even split
the wm code from the ddb code, or to keep them together.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 41 +---
drivers/gpu/drm/i915/intel_pm.c | 37 ++
drivers/gpu/drm/i915/intel_pm.h | 2 +
3 files changed, 41 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 659b952c8e2f..6e96756f9a69 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15291,43 +15291,6 @@ static void intel_update_trans_port_sync_crtcs(struct
intel_crtc *crtc,
state);
}
-static void icl_dbuf_slice_pre_update(struct intel_atomic_state *state)
-{
- struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- const struct intel_dbuf_state *new_dbuf_state =
- intel_atomic_get_new_dbuf_state(state);
- const struct intel_dbuf_state *old_dbuf_state =
- intel_atomic_get_old_dbuf_state(state);
-
- if (!new_dbuf_state ||
- new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
- return;
-
- WARN_ON(!new_dbuf_state->base.changed);
-
- gen9_dbuf_slices_update(dev_priv,
- old_dbuf_state->enabled_slices |
- new_dbuf_state->enabled_slices);
-}
-
-static void icl_dbuf_slice_post_update(struct intel_atomic_state *state)
-{
- struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- const struct intel_dbuf_state *new_dbuf_state =
- intel_atomic_get_new_dbuf_state(state);
- const struct intel_dbuf_state *old_dbuf_state =
- intel_atomic_get_old_dbuf_state(state);
-
- if (!new_dbuf_state ||
- new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
- return;
-
- WARN_ON(!new_dbuf_state->base.changed);
-
- gen9_dbuf_slices_update(dev_priv,
- new_dbuf_state->enabled_slices);
-}
-
static void skl_commit_modeset_enables(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
@@ -15580,7 +15543,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
if (state->modeset)
intel_encoders_update_prepare(state);
- icl_dbuf_slice_pre_update(state);
+ intel_dbuf_pre_plane_update(state);
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.commit_modeset_enables(state);
@@ -15635,7 +15598,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
dev_priv->display.optimize_watermarks(state, crtc);
}
- icl_dbuf_slice_post_update(state);
+ intel_dbuf_post_plane_update(state);
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
intel_post_plane_update(state, crtc);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 87f88ea6b7ae..de2822e5c62c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7553,3 +7553,40 @@ int intel_dbuf_init(struct drm_i915_private *dev_priv)
return 0;
}
+
+void intel_dbuf_pre_plane_update(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ const struct intel_dbuf_state *new_dbuf_state =
+ intel_atomic_get_new_dbuf_state(state);
+ const struct intel_dbuf_state *old_dbuf_state =
+ intel_atomic_get_old_dbuf_state(state);
+
+ if (!new_dbuf_state ||
+ new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
+ return;
+
+ WARN_ON(!new_dbuf_state->base.changed);
+
+ gen9_dbuf_slices_update(dev_priv,
+ old_dbuf_state->enabled_slices |
+ new_dbuf_state->enabled_slices);
+}
+
+void intel_dbuf_post_plane_update(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ const struct intel_dbuf_state *new_dbuf_state =
+ intel_atomic_get_new_dbuf_state(state);
+ const struct intel_dbuf_state *old_dbuf_state =
+ intel_atomic_get_old_dbuf_state(state);
+
+ if (!new_dbuf_state ||
+ new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
+ return;
+
[Intel-gfx] [PATCH v2 08/20] drm/i915: Introduce proper dbuf state
From: Ville Syrjälä
Add a global state to track the dbuf slices. Gets rid of all the nasty
coupling between state->modeset and dbuf recomputation. Also we can now
totally nuke state->active_pipe_changes.
dev_priv->wm.distrust_bios_wm still remains, but that too will get
nuked soon.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 67 +--
.../drm/i915/display/intel_display_power.c| 8 +-
.../drm/i915/display/intel_display_types.h| 13 --
drivers/gpu/drm/i915/i915_drv.h | 11 +-
drivers/gpu/drm/i915/intel_pm.c | 189 --
drivers/gpu/drm/i915/intel_pm.h | 22 ++
6 files changed, 209 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6952c398cc43..659b952c8e2f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7581,6 +7581,8 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
*crtc,
to_intel_bw_state(dev_priv->bw_obj.state);
struct intel_cdclk_state *cdclk_state =
to_intel_cdclk_state(dev_priv->cdclk.obj.state);
+ struct intel_dbuf_state *dbuf_state =
+ to_intel_dbuf_state(dev_priv->dbuf.obj.state);
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
enum intel_display_power_domain domain;
@@ -7654,6 +7656,8 @@ static void intel_crtc_disable_noatomic(struct intel_crtc
*crtc,
cdclk_state->min_voltage_level[pipe] = 0;
cdclk_state->active_pipes &= ~BIT(pipe);
+ dbuf_state->active_pipes &= ~BIT(pipe);
+
bw_state->data_rate[pipe] = 0;
bw_state->num_active_planes[pipe] = 0;
}
@@ -13991,10 +13995,10 @@ static void verify_wm_state(struct intel_crtc *crtc,
hw_enabled_slices = intel_enabled_dbuf_slices_mask(dev_priv);
if (INTEL_GEN(dev_priv) >= 11 &&
- hw_enabled_slices != dev_priv->enabled_dbuf_slices_mask)
+ hw_enabled_slices != dev_priv->dbuf.enabled_slices)
drm_err(_priv->drm,
"mismatch in DBUF Slices (expected 0x%x, got 0x%x)\n",
- dev_priv->enabled_dbuf_slices_mask,
+ dev_priv->dbuf.enabled_slices,
hw_enabled_slices);
/* planes */
@@ -14529,9 +14533,7 @@ static int intel_modeset_checks(struct
intel_atomic_state *state)
state->modeset = true;
state->active_pipes = intel_calc_active_pipes(state,
dev_priv->active_pipes);
- state->active_pipe_changes = state->active_pipes ^
dev_priv->active_pipes;
-
- if (state->active_pipe_changes) {
+ if (state->active_pipes != dev_priv->active_pipes) {
ret = _intel_atomic_lock_global_state(state);
if (ret)
return ret;
@@ -15292,22 +15294,38 @@ static void intel_update_trans_port_sync_crtcs(struct
intel_crtc *crtc,
static void icl_dbuf_slice_pre_update(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask;
- u8 required_slices = state->enabled_dbuf_slices_mask;
- u8 slices_union = hw_enabled_slices | required_slices;
+ const struct intel_dbuf_state *new_dbuf_state =
+ intel_atomic_get_new_dbuf_state(state);
+ const struct intel_dbuf_state *old_dbuf_state =
+ intel_atomic_get_old_dbuf_state(state);
- if (INTEL_GEN(dev_priv) >= 11 && slices_union != hw_enabled_slices)
- gen9_dbuf_slices_update(dev_priv, slices_union);
+ if (!new_dbuf_state ||
+ new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
+ return;
+
+ WARN_ON(!new_dbuf_state->base.changed);
+
+ gen9_dbuf_slices_update(dev_priv,
+ old_dbuf_state->enabled_slices |
+ new_dbuf_state->enabled_slices);
}
static void icl_dbuf_slice_post_update(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask;
- u8 required_slices = state->enabled_dbuf_slices_mask;
+ const struct intel_dbuf_state *new_dbuf_state =
+ intel_atomic_get_new_dbuf_state(state);
+ const struct intel_dbuf_state *old_dbuf_state =
+ intel_atomic_get_old_dbuf_state(state);
- if (INTEL_GEN(dev_priv) >= 11 && required_slices != hw_enabled_slices)
- gen9_dbuf_slices_update(dev_priv, required_slices);
+ if (!new_dbuf_state ||
+ new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
+ return;
+
+ WARN_ON(!new_dbuf_state->base.changed);
+
+
[Intel-gfx] [PATCH v2 06/20] drm/i915: Polish some dbuf debugs
From: Ville Syrjälä
Polish some of the dbuf code to give more meaningful debug
messages and whatnot. Also we can switch over to the per-device
debugs/warns at the same time.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_power.c| 40 +--
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 6e25a1317161..e81e561e8ac0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4433,11 +4433,12 @@ static void intel_power_domains_sync_hw(struct
drm_i915_private *dev_priv)
mutex_unlock(_domains->lock);
}
-static inline
-bool intel_dbuf_slice_set(struct drm_i915_private *dev_priv,
- i915_reg_t reg, bool enable)
+static void intel_dbuf_slice_set(struct drm_i915_private *dev_priv,
+enum dbuf_slice slice, bool enable)
{
- u32 val, status;
+ i915_reg_t reg = DBUF_CTL_S(slice);
+ bool state;
+ u32 val;
val = intel_de_read(dev_priv, reg);
val = enable ? (val | DBUF_POWER_REQUEST) : (val & ~DBUF_POWER_REQUEST);
@@ -4445,13 +4446,10 @@ bool intel_dbuf_slice_set(struct drm_i915_private
*dev_priv,
intel_de_posting_read(dev_priv, reg);
udelay(10);
- status = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
- if ((enable && !status) || (!enable && status)) {
- drm_err(_priv->drm, "DBus power %s timeout!\n",
- enable ? "enable" : "disable");
- return false;
- }
- return true;
+ state = intel_de_read(dev_priv, reg) & DBUF_POWER_STATE;
+ drm_WARN(_priv->drm, enable != state,
+"DBuf slice %d power %s timeout!\n",
+slice, enable ? "enable" : "disable");
}
static void gen9_dbuf_enable(struct drm_i915_private *dev_priv)
@@ -4467,14 +4465,16 @@ static void gen9_dbuf_disable(struct drm_i915_private
*dev_priv)
void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
u8 req_slices)
{
- int i;
- int max_slices = INTEL_INFO(dev_priv)->num_supported_dbuf_slices;
+ int num_slices = INTEL_INFO(dev_priv)->num_supported_dbuf_slices;
struct i915_power_domains *power_domains = _priv->power_domains;
+ enum dbuf_slice slice;
- drm_WARN(_priv->drm, hweight8(req_slices) > max_slices,
-"Invalid number of dbuf slices requested\n");
+ drm_WARN(_priv->drm, req_slices & ~(BIT(num_slices) - 1),
+"Invalid set of dbuf slices (0x%x) requested (num dbuf slices
%d)\n",
+req_slices, num_slices);
- DRM_DEBUG_KMS("Updating dbuf slices to 0x%x\n", req_slices);
+ drm_dbg_kms(_priv->drm,
+ "Updating dbuf slices to 0x%x\n", req_slices);
/*
* Might be running this in parallel to gen9_dc_off_power_well_enable
@@ -4485,11 +4485,9 @@ void icl_dbuf_slices_update(struct drm_i915_private
*dev_priv,
*/
mutex_lock(_domains->lock);
- for (i = 0; i < max_slices; i++) {
- intel_dbuf_slice_set(dev_priv,
-DBUF_CTL_S(i),
-(req_slices & BIT(i)) != 0);
- }
+ for (slice = DBUF_S1; slice < num_slices; slice++)
+ intel_dbuf_slice_set(dev_priv, slice,
+req_slices & BIT(slice));
dev_priv->enabled_dbuf_slices_mask = req_slices;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/20] drm/i915: Nuke skl_ddb_get_hw_state()
From: Ville Syrjälä
skl_ddb_get_hw_state() is redundant and kinda called in thw wrong
spot anyway. Just kill it.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 7 ---
drivers/gpu/drm/i915/intel_pm.h | 1 -
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d4730d9b4e1b..87f88ea6b7ae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4117,12 +4117,6 @@ void skl_pipe_ddb_get_hw_state(struct intel_crtc *crtc,
intel_display_power_put(dev_priv, power_domain, wakeref);
}
-void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv)
-{
- dev_priv->dbuf.enabled_slices =
- intel_enabled_dbuf_slices_mask(dev_priv);
-}
-
/*
* Determines the downscale amount of a plane for the purposes of watermark
calculations.
* The bspec defines downscale amount as:
@@ -5910,7 +5904,6 @@ void skl_wm_get_hw_state(struct drm_i915_private
*dev_priv)
struct intel_crtc *crtc;
struct intel_crtc_state *crtc_state;
- skl_ddb_get_hw_state(dev_priv);
for_each_intel_crtc(_priv->drm, crtc) {
crtc_state = to_intel_crtc_state(crtc->base.state);
diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
index fadf7cbc44c4..1054a0ab1e40 100644
--- a/drivers/gpu/drm/i915/intel_pm.h
+++ b/drivers/gpu/drm/i915/intel_pm.h
@@ -38,7 +38,6 @@ u8 intel_enabled_dbuf_slices_mask(struct drm_i915_private
*dev_priv);
void skl_pipe_ddb_get_hw_state(struct intel_crtc *crtc,
struct skl_ddb_entry *ddb_y,
struct skl_ddb_entry *ddb_uv);
-void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv);
void skl_pipe_wm_get_hw_state(struct intel_crtc *crtc,
struct skl_pipe_wm *out);
void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 18/20] drm/i915: Encapsulate dbuf state handling harder
From: Ville Syrjälä
In order to make the dbuf state computation less fragile
let's make it stand on its own feet by now requiring someone
to peek into a crystall ball ahead of time to figure out
which pipes need to be added to the state under which potential
future conditions. Instead we compute each piece of the state
as we go along, and if any fallout occurs that affects more than
the current set of pipes we add the affected pipes to the state
naturally.
That requires that we track a few extra thigns in the global
dbuf state: dbuf slices for each pipe, and the weight each
pipe has when distributing the same set of slice(s) between
multiple pipes. Easy enough.
We do need to follow a somewhat careful sequence of computations
though as there are several steps involved in cooking up the dbuf
state. Thoguh we could avoid some of that by computing more things
on demand instead of relying on earlier step of the algorithm to
have filled it out. I think the end result is still reasonable
as the entire sequence is pretty much consolidated into a single
function instead of being spread around all over.
The rough sequence is this:
1. calculate active_pipes
2. calculate dbuf slices for every pipe
3. calculate total enabled slices
4. calculate new dbuf weights for any crtc in the state
5. calculate new ddb entry for every pipe based on the sets of
slices and weights, and add any affected crtc to the state
6. calculate new plane ddb entries for all crtcs in the state,
and add any affected plane to the state so that we'll perform
the requisite hw reprogramming
And as a nice bonus we get to throw dev_priv->wm.distrust_bios_wm
out the window.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 15 -
.../drm/i915/display/intel_display_debugfs.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 9 -
drivers/gpu/drm/i915/intel_pm.c | 356 +++---
drivers/gpu/drm/i915/intel_pm.h | 2 +
5 files changed, 138 insertions(+), 245 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 26e4462151a6..e3df43f3932d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14856,20 +14856,6 @@ static int intel_atomic_check(struct drm_device *dev,
if (new_cdclk_state && new_cdclk_state->force_min_cdclk_changed)
any_ms = true;
- /*
-* distrust_bios_wm will force a full dbuf recomputation
-* but the hardware state will only get updated accordingly
-* if state->modeset==true. Hence distrust_bios_wm==true &&
-* state->modeset==false is an invalid combination which
-* would cause the hardware and software dbuf state to get
-* out of sync. We must prevent that.
-*
-* FIXME clean up this mess and introduce better
-* state tracking for dbuf.
-*/
- if (dev_priv->wm.distrust_bios_wm)
- any_ms = true;
-
if (any_ms) {
ret = intel_modeset_checks(state);
if (ret)
@@ -15769,7 +15755,6 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
return ret;
}
- dev_priv->wm.distrust_bios_wm = false;
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 46954cc7b6c0..b505de6287e6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -998,7 +998,6 @@ static ssize_t i915_ipc_status_write(struct file *file,
const char __user *ubuf,
if (!dev_priv->ipc_enabled && enable)
drm_info(_priv->drm,
"Enabling IPC: WM will be proper only after
next commit\n");
- dev_priv->wm.distrust_bios_wm = true;
dev_priv->ipc_enabled = enable;
intel_enable_ipc(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d03c84f373e6..317e6a468e2e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1183,15 +1183,6 @@ struct drm_i915_private {
* crtc_state->wm.need_postvbl_update.
*/
struct mutex wm_mutex;
-
- /*
-* Set during HW readout of watermarks/DDB. Some platforms
-* need to know when we're still using BIOS-provided values
-* (which we don't fully trust).
-*
-* FIXME get rid of this.
-*/
- bool distrust_bios_wm;
} wm;
struct dram_info {
diff --git
[Intel-gfx] [PATCH v2 04/20] drm/i915: Use a sentinel to terminate the dbuf slice arrays
From: Ville Syrjälä
Make life a bit simpler by sticking a sentinel at the end of
the dbuf slice arrays. This way we don't need to pass in the
size. Also unify the types (u8 vs. u32) for active_pipes.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 34 +
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index abeb4b19071f..a2e78969c0df 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3843,7 +3843,7 @@ static u16 intel_get_ddb_size(struct drm_i915_private
*dev_priv)
}
static u8 skl_compute_dbuf_slices(const struct intel_crtc_state *crtc_state,
- u32 active_pipes);
+ u8 active_pipes);
static void
skl_ddb_get_pipe_allocation_limits(struct drm_i915_private *dev_priv,
@@ -4228,6 +4228,7 @@ static const struct dbuf_slice_conf_entry
icl_allowed_dbufs[] =
[PIPE_C] = BIT(DBUF_S2),
},
},
+ {}
};
/*
@@ -4350,16 +4351,15 @@ static const struct dbuf_slice_conf_entry
tgl_allowed_dbufs[] =
[PIPE_D] = BIT(DBUF_S2),
},
},
+ {}
};
-static u8 compute_dbuf_slices(enum pipe pipe,
- u32 active_pipes,
- const struct dbuf_slice_conf_entry *dbuf_slices,
- int size)
+static u8 compute_dbuf_slices(enum pipe pipe, u8 active_pipes,
+ const struct dbuf_slice_conf_entry *dbuf_slices)
{
int i;
- for (i = 0; i < size; i++) {
+ for (i = 0; i < dbuf_slices[i].active_pipes; i++) {
if (dbuf_slices[i].active_pipes == active_pipes)
return dbuf_slices[i].dbuf_mask[pipe];
}
@@ -4371,8 +4371,7 @@ static u8 compute_dbuf_slices(enum pipe pipe,
* returns correspondent DBuf slice mask as stated in BSpec for particular
* platform.
*/
-static u32 icl_compute_dbuf_slices(enum pipe pipe,
- u32 active_pipes)
+static u8 icl_compute_dbuf_slices(enum pipe pipe, u8 active_pipes)
{
/*
* FIXME: For ICL this is still a bit unclear as prev BSpec revision
@@ -4386,32 +4385,25 @@ static u32 icl_compute_dbuf_slices(enum pipe pipe,
* still here - we will need it once those additional constraints
* pop up.
*/
- return compute_dbuf_slices(pipe, active_pipes,
- icl_allowed_dbufs,
- ARRAY_SIZE(icl_allowed_dbufs));
+ return compute_dbuf_slices(pipe, active_pipes, icl_allowed_dbufs);
}
-static u32 tgl_compute_dbuf_slices(enum pipe pipe,
- u32 active_pipes)
+static u8 tgl_compute_dbuf_slices(enum pipe pipe, u8 active_pipes)
{
- return compute_dbuf_slices(pipe, active_pipes,
- tgl_allowed_dbufs,
- ARRAY_SIZE(tgl_allowed_dbufs));
+ return compute_dbuf_slices(pipe, active_pipes, tgl_allowed_dbufs);
}
static u8 skl_compute_dbuf_slices(const struct intel_crtc_state *crtc_state,
- u32 active_pipes)
+ u8 active_pipes)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
if (IS_GEN(dev_priv, 12))
- return tgl_compute_dbuf_slices(pipe,
- active_pipes);
+ return tgl_compute_dbuf_slices(pipe, active_pipes);
else if (IS_GEN(dev_priv, 11))
- return icl_compute_dbuf_slices(pipe,
- active_pipes);
+ return icl_compute_dbuf_slices(pipe, active_pipes);
/*
* For anything else just return one slice yet.
* Should be extended for other platforms.
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/20] drm/i915: Pass the crtc to skl_compute_dbuf_slices()
From: Ville Syrjälä
skl_compute_dbuf_slices() has no use for the crtc state, so
just pass the crtc itself.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3f48ce7517e2..256622b603cd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3861,7 +3861,7 @@ static unsigned int intel_crtc_ddb_weight(const struct
intel_crtc_state *crtc_st
return hdisplay;
}
-static u8 skl_compute_dbuf_slices(const struct intel_crtc_state *crtc_state,
+static u8 skl_compute_dbuf_slices(struct intel_crtc *crtc,
u8 active_pipes);
static int
@@ -3873,10 +3873,10 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
{
struct drm_atomic_state *state = crtc_state->uapi.state;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct drm_crtc *for_crtc = crtc_state->uapi.crtc;
- const struct intel_crtc *crtc;
+ struct intel_crtc *for_crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct intel_crtc *crtc;
unsigned int pipe_weight = 0, total_weight = 0, weight_before_pipe = 0;
- enum pipe for_pipe = to_intel_crtc(for_crtc)->pipe;
+ enum pipe for_pipe = for_crtc->pipe;
struct intel_dbuf_state *new_dbuf_state =
intel_atomic_get_new_dbuf_state(intel_state);
const struct intel_dbuf_state *old_dbuf_state =
@@ -3920,14 +3920,14 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
*
* FIXME get rid of this mess
*/
- *alloc = to_intel_crtc_state(for_crtc->state)->wm.skl.ddb;
+ *alloc = to_intel_crtc_state(for_crtc->base.state)->wm.skl.ddb;
return 0;
}
/*
* Get allowed DBuf slices for correspondent pipe and platform.
*/
- dbuf_slice_mask = skl_compute_dbuf_slices(crtc_state, active_pipes);
+ dbuf_slice_mask = skl_compute_dbuf_slices(for_crtc, active_pipes);
/*
* Figure out at which DBuf slice we start, i.e if we start at Dbuf S2
@@ -3953,8 +3953,8 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
if (!crtc_state->hw.active)
continue;
- pipe_dbuf_slice_mask = skl_compute_dbuf_slices(crtc_state,
- active_pipes);
+ pipe_dbuf_slice_mask =
+ skl_compute_dbuf_slices(crtc, active_pipes);
/*
* According to BSpec pipe can share one dbuf slice with another
@@ -4004,7 +4004,7 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
drm_dbg_kms(_priv->drm,
"[CRTC:%d:%s] dbuf slices 0x%x, ddb (%d - %d), active pipes
0x%x\n",
- for_crtc->base.id, for_crtc->name,
+ for_crtc->base.base.id, for_crtc->base.name,
dbuf_slice_mask, alloc->start, alloc->end, active_pipes);
return 0;
@@ -4402,10 +4402,8 @@ static u8 tgl_compute_dbuf_slices(enum pipe pipe, u8
active_pipes)
return compute_dbuf_slices(pipe, active_pipes, tgl_allowed_dbufs);
}
-static u8 skl_compute_dbuf_slices(const struct intel_crtc_state *crtc_state,
- u8 active_pipes)
+static u8 skl_compute_dbuf_slices(struct intel_crtc *crtc, u8 active_pipes)
{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/20] drm/i915: Add missing commas to dbuf tables
From: Ville Syrjälä
The preferred style is to sprinkle commas after each array and
structure initialization, whether or not it happens to be the
last element/member (only exception being sentinel entries which
never have anything after them). This leads to much prettier
diffs if/when new elements/members get added to the end of the
initialization. We're not bound by some ancient silly mandate
to omit the final comma.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 88 -
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 59fc461bc454..abeb4b19071f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4184,49 +4184,49 @@ static const struct dbuf_slice_conf_entry
icl_allowed_dbufs[] =
{
.active_pipes = BIT(PIPE_A),
.dbuf_mask = {
- [PIPE_A] = BIT(DBUF_S1)
- }
+ [PIPE_A] = BIT(DBUF_S1),
+ },
},
{
.active_pipes = BIT(PIPE_B),
.dbuf_mask = {
- [PIPE_B] = BIT(DBUF_S1)
- }
+ [PIPE_B] = BIT(DBUF_S1),
+ },
},
{
.active_pipes = BIT(PIPE_A) | BIT(PIPE_B),
.dbuf_mask = {
[PIPE_A] = BIT(DBUF_S1),
- [PIPE_B] = BIT(DBUF_S2)
- }
+ [PIPE_B] = BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_C),
.dbuf_mask = {
- [PIPE_C] = BIT(DBUF_S2)
- }
+ [PIPE_C] = BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_A) | BIT(PIPE_C),
.dbuf_mask = {
[PIPE_A] = BIT(DBUF_S1),
- [PIPE_C] = BIT(DBUF_S2)
- }
+ [PIPE_C] = BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_B) | BIT(PIPE_C),
.dbuf_mask = {
[PIPE_B] = BIT(DBUF_S1),
- [PIPE_C] = BIT(DBUF_S2)
- }
+ [PIPE_C] = BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
.dbuf_mask = {
[PIPE_A] = BIT(DBUF_S1),
[PIPE_B] = BIT(DBUF_S1),
- [PIPE_C] = BIT(DBUF_S2)
- }
+ [PIPE_C] = BIT(DBUF_S2),
+ },
},
};
@@ -4246,100 +4246,100 @@ static const struct dbuf_slice_conf_entry
tgl_allowed_dbufs[] =
{
.active_pipes = BIT(PIPE_A),
.dbuf_mask = {
- [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2)
- }
+ [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_B),
.dbuf_mask = {
- [PIPE_B] = BIT(DBUF_S1) | BIT(DBUF_S2)
- }
+ [PIPE_B] = BIT(DBUF_S1) | BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_A) | BIT(PIPE_B),
.dbuf_mask = {
[PIPE_A] = BIT(DBUF_S2),
- [PIPE_B] = BIT(DBUF_S1)
- }
+ [PIPE_B] = BIT(DBUF_S1),
+ },
},
{
.active_pipes = BIT(PIPE_C),
.dbuf_mask = {
- [PIPE_C] = BIT(DBUF_S2) | BIT(DBUF_S1)
- }
+ [PIPE_C] = BIT(DBUF_S2) | BIT(DBUF_S1),
+ },
},
{
.active_pipes = BIT(PIPE_A) | BIT(PIPE_C),
.dbuf_mask = {
[PIPE_A] = BIT(DBUF_S1),
- [PIPE_C] = BIT(DBUF_S2)
- }
+ [PIPE_C] = BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_B) | BIT(PIPE_C),
.dbuf_mask = {
[PIPE_B] = BIT(DBUF_S1),
- [PIPE_C] = BIT(DBUF_S2)
- }
+ [PIPE_C] = BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
.dbuf_mask = {
[PIPE_A] = BIT(DBUF_S1),
[PIPE_B] = BIT(DBUF_S1),
- [PIPE_C] = BIT(DBUF_S2)
- }
+ [PIPE_C] = BIT(DBUF_S2),
+ },
},
{
.active_pipes = BIT(PIPE_D),
[Intel-gfx] [PATCH v2 17/20] drm/i915: Extract intel_crtc_dbuf_weights()
From: Ville Syrjälä
Extract the code to calculate the weights used to chunk up the dbuf
between pipes. There's still extra stuff in there that shouldn't be
there and must be moved out, but that requires a bit more state to
be tracked in the dbuf state.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 145
1 file changed, 89 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b33d99a30116..085043528f80 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3868,62 +3868,35 @@ static unsigned int intel_crtc_ddb_weight(const struct
intel_crtc_state *crtc_st
static u8 skl_compute_dbuf_slices(struct intel_crtc *crtc,
u8 active_pipes);
-static int
-skl_ddb_get_pipe_allocation_limits(struct drm_i915_private *dev_priv,
- const struct intel_crtc_state *crtc_state,
- const u64 total_data_rate,
- struct skl_ddb_entry *alloc, /* out */
- int *num_active /* out */)
+static int intel_crtc_dbuf_weights(struct intel_atomic_state *state,
+ struct intel_crtc *for_crtc,
+ unsigned int *weight_start,
+ unsigned int *weight_end,
+ unsigned int *weight_total)
{
- struct drm_atomic_state *state = crtc_state->uapi.state;
- struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
- struct intel_crtc *for_crtc = to_intel_crtc(crtc_state->uapi.crtc);
- struct intel_crtc *crtc;
- unsigned int pipe_weight = 0, total_weight = 0, weight_before_pipe = 0;
+ const struct intel_dbuf_state *old_dbuf_state =
+ intel_atomic_get_old_dbuf_state(state);
+ struct intel_dbuf_state *new_dbuf_state =
+ intel_atomic_get_new_dbuf_state(state);
+ u8 active_pipes = new_dbuf_state->active_pipes;
enum pipe for_pipe = for_crtc->pipe;
- struct intel_dbuf_state *new_dbuf_state =
- intel_atomic_get_new_dbuf_state(intel_state);
- const struct intel_dbuf_state *old_dbuf_state =
- intel_atomic_get_old_dbuf_state(intel_state);
- u8 active_pipes = new_dbuf_state->active_pipes;
- struct skl_ddb_entry ddb_slices;
- u32 ddb_range_size;
- u32 i;
- u32 dbuf_slice_mask;
- u32 total_slice_mask;
- u32 start, end;
- int ret;
-
- *num_active = hweight8(active_pipes);
-
- if (!crtc_state->hw.active) {
- alloc->start = 0;
- alloc->end = 0;
- return 0;
- }
-
- /*
-* If the state doesn't change the active CRTC's or there is no
-* modeset request, then there's no need to recalculate;
-* the existing pipe allocation limits should remain unchanged.
-* Note that we're safe from racing commits since any racing commit
-* that changes the active CRTC list or do modeset would need to
-* grab _all_ crtc locks, including the one we currently hold.
-*/
- if (old_dbuf_state->active_pipes == new_dbuf_state->active_pipes &&
- !dev_priv->wm.distrust_bios_wm)
- return 0;
+ const struct intel_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
+ u8 dbuf_slice_mask;
+ u8 total_slice_mask;
+ int i, ret;
/*
* Get allowed DBuf slices for correspondent pipe and platform.
*/
dbuf_slice_mask = skl_compute_dbuf_slices(for_crtc, active_pipes);
-
- skl_ddb_entry_for_slices(dev_priv, dbuf_slice_mask, _slices);
- ddb_range_size = skl_ddb_entry_size(_slices);
-
total_slice_mask = dbuf_slice_mask;
- for_each_new_intel_crtc_in_state(intel_state, crtc, crtc_state, i) {
+
+ *weight_start = 0;
+ *weight_end = 0;
+ *weight_total = 0;
+
+ for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
enum pipe pipe = crtc->pipe;
unsigned int weight;
u8 pipe_dbuf_slice_mask;
@@ -3954,12 +3927,14 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
continue;
weight = intel_crtc_ddb_weight(crtc_state);
- total_weight += weight;
+ *weight_total += weight;
- if (pipe < for_pipe)
- weight_before_pipe += weight;
- else if (pipe == for_pipe)
- pipe_weight = weight;
+ if (pipe < for_pipe) {
+ *weight_start += weight;
+ *weight_end += weight;
+ } else if (pipe == for_pipe) {
+ *weight_end += weight;
+
[Intel-gfx] [PATCH v2 16/20] drm/i915: Move pipe ddb entries into the dbuf state
From: Ville Syrjälä
The dbuf state will be where we collect all the inter-pipe dbuf
allocation stuff. Start by moving the actual per-pipe ddb entries
there.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 28 +++
.../drm/i915/display/intel_display_types.h| 1 -
drivers/gpu/drm/i915/intel_pm.c | 16 ---
drivers/gpu/drm/i915/intel_pm.h | 4 +++
4 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6e96756f9a69..26e4462151a6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15294,6 +15294,10 @@ static void intel_update_trans_port_sync_crtcs(struct
intel_crtc *crtc,
static void skl_commit_modeset_enables(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ const struct intel_dbuf_state *old_dbuf_state =
+ intel_atomic_get_old_dbuf_state(state);
+ const struct intel_dbuf_state *new_dbuf_state =
+ intel_atomic_get_new_dbuf_state(state);
struct intel_crtc *crtc;
struct intel_crtc_state *old_crtc_state, *new_crtc_state;
struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
@@ -15309,7 +15313,7 @@ static void skl_commit_modeset_enables(struct
intel_atomic_state *state)
/* ignore allocations for crtc's that have been turned off. */
if (!needs_modeset(new_crtc_state)) {
- entries[pipe] = old_crtc_state->wm.skl.ddb;
+ entries[pipe] = old_dbuf_state->ddb[pipe];
update_pipes |= BIT(pipe);
} else {
modeset_pipes |= BIT(pipe);
@@ -15333,11 +15337,11 @@ static void skl_commit_modeset_enables(struct
intel_atomic_state *state)
if ((update_pipes & BIT(pipe)) == 0)
continue;
- if
(skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
+ if
(skl_ddb_allocation_overlaps(_dbuf_state->ddb[pipe],
entries, num_pipes,
pipe))
continue;
- entries[pipe] = new_crtc_state->wm.skl.ddb;
+ entries[pipe] = new_dbuf_state->ddb[pipe];
update_pipes &= ~BIT(pipe);
intel_update_crtc(crtc, state, old_crtc_state,
@@ -15349,8 +15353,8 @@ static void skl_commit_modeset_enables(struct
intel_atomic_state *state)
* then we need to wait for a vblank to pass for the
* new ddb allocation to take effect.
*/
- if (!skl_ddb_entry_equal(_crtc_state->wm.skl.ddb,
-_crtc_state->wm.skl.ddb) &&
+ if (!skl_ddb_entry_equal(_dbuf_state->ddb[pipe],
+_dbuf_state->ddb[pipe]) &&
(update_pipes | modeset_pipes))
intel_wait_for_vblank(dev_priv, pipe);
}
@@ -15371,10 +15375,11 @@ static void skl_commit_modeset_enables(struct
intel_atomic_state *state)
is_trans_port_sync_slave(new_crtc_state))
continue;
- drm_WARN_ON(_priv->drm,
skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
-
entries, num_pipes, pipe));
+ drm_WARN_ON(_priv->drm,
+
skl_ddb_allocation_overlaps(_dbuf_state->ddb[pipe],
+ entries, num_pipes,
pipe));
- entries[pipe] = new_crtc_state->wm.skl.ddb;
+ entries[pipe] = new_dbuf_state->ddb[pipe];
modeset_pipes &= ~BIT(pipe);
if (is_trans_port_sync_mode(new_crtc_state)) {
@@ -15406,10 +15411,11 @@ static void skl_commit_modeset_enables(struct
intel_atomic_state *state)
if ((modeset_pipes & BIT(pipe)) == 0)
continue;
- drm_WARN_ON(_priv->drm,
skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
-
entries, num_pipes, pipe));
+ drm_WARN_ON(_priv->drm,
+
skl_ddb_allocation_overlaps(_dbuf_state->ddb[pipe],
+ entries, num_pipes,
pipe));
- entries[pipe] = new_crtc_state->wm.skl.ddb;
+ entries[pipe] = new_dbuf_state->ddb[pipe];
modeset_pipes &= ~BIT(pipe);
intel_update_crtc(crtc, state,
[Intel-gfx] [PATCH v2 11/20] drm/i915: Clean up dbuf debugs during .atomic_check()
From: Ville Syrjälä
Combine the two per-pipe dbuf debugs into one, and use the canonical
[CRTC:%d:%s] style to identify the crtc. Also use the same style as
the plane code uses for the ddb start/end, and prefix bitmask properly
with 0x to make it clear they are in fact bitmasks.
The "how many total slices we are going to use" debug we move to
outside the crtc loop so it gets printed only once at the end.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index de2822e5c62c..d2edfb820dd9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3910,10 +3910,6 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
*/
dbuf_slice_mask = skl_compute_dbuf_slices(crtc_state, active_pipes);
- DRM_DEBUG_KMS("DBuf slice mask %x pipe %c active pipes %x\n",
- dbuf_slice_mask,
- pipe_name(for_pipe), active_pipes);
-
/*
* Figure out at which DBuf slice we start, i.e if we start at Dbuf S2
* and slice size is 1024, the offset would be 1024
@@ -3996,8 +3992,10 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
alloc->start = offset + start;
alloc->end = offset + end;
- DRM_DEBUG_KMS("Pipe %d ddb %d-%d\n", for_pipe,
- alloc->start, alloc->end);
+ drm_dbg_kms(_priv->drm,
+ "[CRTC:%d:%s] dbuf slices 0x%x, ddb (%d - %d), active pipes
0x%x\n",
+ for_crtc->base.id, for_crtc->name,
+ dbuf_slice_mask, alloc->start, alloc->end, active_pipes);
return 0;
}
@@ -5457,7 +5455,10 @@ skl_ddb_add_affected_planes(const struct
intel_crtc_state *old_crtc_state,
static int
skl_compute_ddb(struct intel_atomic_state *state)
{
- struct intel_crtc_state *old_crtc_state;
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ const struct intel_dbuf_state *old_dbuf_state;
+ const struct intel_dbuf_state *new_dbuf_state;
+ const struct intel_crtc_state *old_crtc_state;
struct intel_crtc_state *new_crtc_state;
struct intel_crtc *crtc;
int ret, i;
@@ -5474,6 +5475,17 @@ skl_compute_ddb(struct intel_atomic_state *state)
return ret;
}
+ old_dbuf_state = intel_atomic_get_old_dbuf_state(state);
+ new_dbuf_state = intel_atomic_get_new_dbuf_state(state);
+
+ if (new_dbuf_state &&
+ new_dbuf_state->enabled_slices != old_dbuf_state->enabled_slices)
+ drm_dbg_kms(_priv->drm,
+ "Enabled dbuf slices 0x%x -> 0x%x (out of %d dbuf
slices)\n",
+ old_dbuf_state->enabled_slices,
+ new_dbuf_state->enabled_slices,
+ INTEL_INFO(dev_priv)->num_supported_dbuf_slices);
+
return 0;
}
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 15/20] drm/i915: Introduce skl_ddb_entry_for_slices()
From: Ville Syrjälä
Generalize icl_get_first_dbuf_slice_offset() into something that
just gives us the start+end of the dbuf chunk covered by the
specified slices as a standard ddb entry. Initial idea was to use
it during readout as well, but we shall see.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 56 +++--
1 file changed, 18 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9baf31e06011..94847225c84f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3827,28 +3827,25 @@ static int intel_dbuf_slice_size(struct
drm_i915_private *dev_priv)
INTEL_INFO(dev_priv)->num_supported_dbuf_slices;
}
-/*
- * Calculate initial DBuf slice offset, based on slice size
- * and mask(i.e if slice size is 1024 and second slice is enabled
- * offset would be 1024)
- */
-static unsigned int
-icl_get_first_dbuf_slice_offset(u32 dbuf_slice_mask,
- u32 slice_size,
- u32 ddb_size)
+static void
+skl_ddb_entry_for_slices(struct drm_i915_private *dev_priv, u8 slice_mask,
+struct skl_ddb_entry *ddb)
{
- unsigned int offset = 0;
+ int slice_size = intel_dbuf_slice_size(dev_priv);
- if (!dbuf_slice_mask)
- return 0;
+ if (!slice_mask) {
+ ddb->start = 0;
+ ddb->end = 0;
+ return;
+ }
- offset = (ffs(dbuf_slice_mask) - 1) * slice_size;
+ ddb->start = (ffs(slice_mask) - 1) * slice_size;
+ ddb->end = fls(slice_mask) * slice_size;
- WARN_ON(offset >= ddb_size);
- return offset;
+ WARN_ON(ddb->start >= ddb->end);
+ WARN_ON(ddb->end > intel_dbuf_size(dev_priv));
}
-
static unsigned int intel_crtc_ddb_weight(const struct intel_crtc_state
*crtc_state)
{
const struct drm_display_mode *adjusted_mode =
@@ -3889,12 +3886,10 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
const struct intel_dbuf_state *old_dbuf_state =
intel_atomic_get_old_dbuf_state(intel_state);
u8 active_pipes = new_dbuf_state->active_pipes;
- u16 ddb_size;
+ struct skl_ddb_entry ddb_slices;
u32 ddb_range_size;
u32 i;
u32 dbuf_slice_mask;
- u32 offset;
- u32 slice_size;
u32 total_slice_mask;
u32 start, end;
int ret;
@@ -3907,9 +3902,6 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
return 0;
}
- ddb_size = intel_dbuf_size(dev_priv);
- slice_size = intel_dbuf_slice_size(dev_priv);
-
/*
* If the state doesn't change the active CRTC's or there is no
* modeset request, then there's no need to recalculate;
@@ -3935,20 +3927,8 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
*/
dbuf_slice_mask = skl_compute_dbuf_slices(for_crtc, active_pipes);
- /*
-* Figure out at which DBuf slice we start, i.e if we start at Dbuf S2
-* and slice size is 1024, the offset would be 1024
-*/
- offset = icl_get_first_dbuf_slice_offset(dbuf_slice_mask,
-slice_size, ddb_size);
-
- /*
-* Figure out total size of allowed DBuf slices, which is basically
-* a number of allowed slices for that pipe multiplied by slice size.
-* Inside of this
-* range ddb entries are still allocated in proportion to display width.
-*/
- ddb_range_size = hweight8(dbuf_slice_mask) * slice_size;
+ skl_ddb_entry_for_slices(dev_priv, dbuf_slice_mask, _slices);
+ ddb_range_size = skl_ddb_entry_size(_slices);
total_slice_mask = dbuf_slice_mask;
for_each_new_intel_crtc_in_state(intel_state, crtc, crtc_state, i) {
@@ -4005,8 +3985,8 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
start = ddb_range_size * weight_before_pipe / total_weight;
end = ddb_range_size * (weight_before_pipe + pipe_weight) /
total_weight;
- alloc->start = offset + start;
- alloc->end = offset + end;
+ alloc->start = ddb_slices.start + start;
+ alloc->end = ddb_slices.start + end;
drm_dbg_kms(_priv->drm,
"[CRTC:%d:%s] dbuf slices 0x%x, ddb (%d - %d), active pipes
0x%x\n",
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/20] drm/i915: Remove garbage WARNs
From: Ville Syrjälä
These things can never happen, and probably we'd have oopsed long ago
if they did. Just get rid of this pointless noise in the code.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 543634d3e10c..59fc461bc454 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4470,14 +4470,10 @@ skl_get_total_relative_data_rate(struct
intel_crtc_state *crtc_state,
u64 *plane_data_rate,
u64 *uv_plane_data_rate)
{
- struct drm_atomic_state *state = crtc_state->uapi.state;
struct intel_plane *plane;
const struct intel_plane_state *plane_state;
u64 total_data_rate = 0;
- if (WARN_ON(!state))
- return 0;
-
/* Calculate and cache data rate for each plane */
intel_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state) {
enum plane_id plane_id = plane->id;
@@ -4505,9 +4501,6 @@ icl_get_total_relative_data_rate(struct intel_crtc_state
*crtc_state,
const struct intel_plane_state *plane_state;
u64 total_data_rate = 0;
- if (WARN_ON(!crtc_state->uapi.state))
- return 0;
-
/* Calculate and cache data rate for each plane */
intel_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state) {
enum plane_id plane_id = plane->id;
@@ -4548,7 +4541,6 @@ icl_get_total_relative_data_rate(struct intel_crtc_state
*crtc_state,
static int
skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
{
- struct drm_atomic_state *state = crtc_state->uapi.state;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct skl_ddb_entry *alloc = _state->wm.skl.ddb;
@@ -4567,9 +4559,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
memset(crtc_state->wm.skl.plane_ddb_y, 0,
sizeof(crtc_state->wm.skl.plane_ddb_y));
memset(crtc_state->wm.skl.plane_ddb_uv, 0,
sizeof(crtc_state->wm.skl.plane_ddb_uv));
- if (drm_WARN_ON(_priv->drm, !state))
- return 0;
-
if (!crtc_state->hw.active) {
alloc->start = alloc->end = 0;
return 0;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Autotune idle timeouts
As we measure how long it takes for each heartbeat when idling the
system, we have a reasonable expectation for the baseline latency when
idling. We can use this baseline to estimate how long we expect it
should take to idle, and so provide a more precise upper bound for
declaring a problem.
References: b81e4d9b5941 ("drm/i915/gt: Track engine round-trip times")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Stuart Summers
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/intel_gt.c| 4 +--
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 27 +++
drivers/gpu/drm/i915/gt/selftest_rc6.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +-
drivers/gpu/drm/i915/i915_gem.h | 2 --
.../gpu/drm/i915/selftests/igt_flush_test.c | 2 +-
7 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 3dea8881e915..4057ac4d350a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -440,7 +440,7 @@ static int __engines_record_defaults(struct intel_gt *gt)
}
/* Flush the default context image to memory, and enable powersaving. */
- if (intel_gt_wait_for_idle(gt, I915_GEM_IDLE_TIMEOUT) == -ETIME) {
+ if (intel_gt_wait_for_idle(gt, 10) == -ETIME) {
err = -EIO;
goto out;
}
@@ -543,7 +543,7 @@ static int __engines_verify_workarounds(struct intel_gt *gt)
}
/* Flush and restore the kernel context for safety */
- if (intel_gt_wait_for_idle(gt, I915_GEM_IDLE_TIMEOUT) == -ETIME)
+ if (intel_gt_wait_for_idle(gt, 10) == -ETIME)
err = -EIO;
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 8b653c0f5e5f..202550c06139 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -248,7 +248,7 @@ static void wait_for_suspend(struct intel_gt *gt)
if (!intel_gt_pm_is_awake(gt))
return;
- if (intel_gt_wait_for_idle(gt, I915_GEM_IDLE_TIMEOUT) == -ETIME) {
+ if (intel_gt_wait_for_idle(gt, 10) == -ETIME) {
/*
* Forcibly cancel outstanding work and leave
* the gpu quiet.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 8a5054f21bf8..5c9797cb3d0b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -180,12 +180,39 @@ long intel_gt_retire_requests_timeout(struct intel_gt
*gt, long timeout)
return active_count ? timeout : 0;
}
+static long
+intel_gt_timeout(struct intel_gt *gt, intel_engine_mask_t mask, int factor)
+{
+ struct intel_engine_cs *engine;
+ intel_engine_mask_t tmp;
+ unsigned long max;
+
+ max = 0;
+ for_each_engine_masked(engine, gt, mask, tmp) {
+ unsigned long latency;
+
+ latency = ewma__engine_latency_read(>latency);
+ if (latency > max)
+ max = latency;
+
+ factor++; /* allow each engine to flush pm sequentially */
+ }
+ if (max == 0) /* no latency measured yet */
+ return MAX_SCHEDULE_TIMEOUT;
+
+ return usecs_to_jiffies(max * factor) + 1;
+}
+
int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout)
{
/* If the device is asleep, we have no requests outstanding */
if (!intel_gt_pm_is_awake(gt))
return 0;
+ /* Adjust our expected jiffie timeout based on historical latency */
+ if (timeout < MAX_SCHEDULE_TIMEOUT)
+ timeout = intel_gt_timeout(gt, ALL_ENGINES, timeout);
+
while ((timeout = intel_gt_retire_requests_timeout(gt, timeout)) > 0) {
cond_resched();
if (signal_pending(current))
diff --git a/drivers/gpu/drm/i915/gt/selftest_rc6.c
b/drivers/gpu/drm/i915/gt/selftest_rc6.c
index 5f7e2dcf5686..70d040b39685 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rc6.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rc6.c
@@ -176,7 +176,7 @@ int live_rc6_ctx_wa(void *arg)
goto out;
}
- if (intel_gt_wait_for_idle(gt, HZ / 5) == -ETIME) {
+ if (intel_gt_wait_for_idle(gt, 2) == -ETIME) {
intel_gt_set_wedged(gt);
err = -ETIME;
goto out;
diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index c2578a0f2f14..31f6ca3e6d76 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -789,7 +789,7 @@ static int live_hwsp_rollover_kernel(void
Re: [Intel-gfx] [RFC PATCH i-g-t v2 2/2] tests/gem_userptr_blits: Exercise mmap-offset mapping to userptr
Quoting Janusz Krzysztofik (2020-02-25 15:41:28) > Hi Chris, > > On Fri, 2020-02-21 at 14:28 +, Chris Wilson wrote: > > Quoting Janusz Krzysztofik (2020-02-21 11:17:01) > > > + /* create userptr object */ > > > + igt_assert_eq(posix_memalign(, PAGE_SIZE, PAGE_SIZE), > > > 0); > > > + gem_userptr(fd, ptr, PAGE_SIZE, 0, userptr_flags, ); > > > + > > > + /* set up mmap-offset mapping on top of the object, skip if > > > refused */ > > > + map = __gem_mmap_offset(fd, handle, 0, PAGE_SIZE, > > > + PROT_READ | PROT_WRITE, t->type); > > > + igt_skip_on_f(!map && errno == -ENODEV, > > errno should be compared against a positive value, sorry for that bug. > Thanks for fixing it and merging. I was lazier than that. I feared we had scrubbed errno. But the fixes were an improvement so had no reason to delay. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm: Nuke mode->vrefresh
On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote:
> On 25.02.2020 12:21, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
> >> On 19.02.2020 21:35, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves
> >>> a bit of space and avoids the cached value getting out of sync
> >>> with reality.
> >>>
> >>> Mostly done with cocci, with the following manual fixups:
> >>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
> >>> - Fix __MODE() macro in ch7006_mode.c
> >>> - Fix DRM_MODE_ARG() macro in drm_modes.h
> >>> - Remove leftover comment from samsung_s6d16d0_mode
> >> ...
> >>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> index 41444a73c980..47b37fef7ee8 100644
> >>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> >>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type
> >>> versatile_panels[] = {
> >>> .vsync_start = 240 + 5,
> >>> .vsync_end = 240 + 5 + 6,
> >>> .vtotal = 240 + 5 + 6 + 5,
> >>> - .vrefresh = 116,
> >>
> >> Are you sure vrefresh calculated (from totals and clock) is different
> >> than this field? If not, we risk regressions.
> >>
> >> This case is OK, but there is plenty other cases.
> > IIRC I did spot check a few of them. But which code exactly do you think
> > is abusing vrefresh and thus could break?
>
>
> I guess suspect/potential victim is every code which uses
> drm_mode_vrefresh - after this patch the function can return different
> value(if there are differences between provided and calculated vrefresh).
>
> Quick examples where output of this function matters:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
Already looks quite sketchy due to rounding.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
msleep() is in no way accurate so looks rather sketchy as well.
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
Another thing that suffers from rounding issues.
So to me these all look like code that someone should fix regardless.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v2 2/2] tests/gem_userptr_blits: Exercise mmap-offset mapping to userptr
Hi Chris,
On Fri, 2020-02-21 at 14:28 +, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> > Currently unavoidable lockedp loop related to userptr MMU notifier
> > exists in the i915 driver. For that reason, attempts to set up a
> > mmap-offset (or mmap-gtt) mapping to a userptr object may be now
> > preventively rejected by the driver.
> >
> > A test should exists which checks for that. Would a mapping
> > attempt
> > succeed, the test should trigger the MMU notifier in a way that is
> > proven to result in the lockdep slpat.
> >
> > As that exercise is strictly userptr related, it has been decided
> > to
> > add it as a new subtest to gem_userptr_blits. The new subtest
> > examines
> > userptr interaction with every supported mmap-offset type mapping
> > on
> > top of it.
> >
> > v2: Move the subtest from gem_mmap_offset to gem_userptr_blits,
> > - use dynamic subtests (Chris),
> > - don't FAIL but SKIP on mmap-offset attempt failure (Chris),
> > - on success, try to anger lockdep (Chris).
> >
> > Suggested-by: Chris Wilson > Signed-off-by: Janusz Krzysztofik <
> > janusz.krzyszto...@linux.intel.com>
> > Cc: Matthew Auld
> > ---
> > In order to be able to prove the proposed method of angering
> > lockdep
> > actually works, I'm going to submit a kernel patch that reverts
> > commit
> > f6c26b555e14 ("drm/i915: Never allow userptr into the new mapping
> > types") to be tested on Trybot together with this one, so at least
> > non-GTT mmap-offset attempts succeed and the MMU notifier is
> > triggered.
> >
> > Thanks,
> > Janusz
> >
> > tests/i915/gem_userptr_blits.c | 42
> > ++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/tests/i915/gem_userptr_blits.c
> > b/tests/i915/gem_userptr_blits.c
> > index fcad374ef..5f716a3ea 100644
> > --- a/tests/i915/gem_userptr_blits.c
> > +++ b/tests/i915/gem_userptr_blits.c
> > @@ -797,6 +797,42 @@ static int test_map_fixed_invalidate(int fd,
> > uint32_t flags)
> > return 0;
> > }
> >
> > +static void test_mmap_offset_invalidate(int fd, const struct
> > mmap_offset *t)
> > +{
> > + void *ptr, *map;
> > + uint32_t handle;
> > +
> > + /* check if mmap_offset type is supported by hardware, skip
> > if not */
> > + handle = gem_create(fd, PAGE_SIZE);
> > + map = __gem_mmap_offset(fd, handle, 0, PAGE_SIZE,
> > + PROT_READ | PROT_WRITE, t->type);
> > + igt_require_f(map,
> > + "HW & kernel support for mmap_offset(%s)\n",
> > t->name);
> > + munmap(map, PAGE_SIZE);
> > + gem_close(fd, handle);
> > +
> > + /* create userptr object */
> > + igt_assert_eq(posix_memalign(, PAGE_SIZE, PAGE_SIZE),
> > 0);
> > + gem_userptr(fd, ptr, PAGE_SIZE, 0, userptr_flags, );
> > +
> > + /* set up mmap-offset mapping on top of the object, skip if
> > refused */
> > + map = __gem_mmap_offset(fd, handle, 0, PAGE_SIZE,
> > + PROT_READ | PROT_WRITE, t->type);
> > + igt_skip_on_f(!map && errno == -ENODEV,
errno should be compared against a positive value, sorry for that bug.
Thanks for fixing it and merging.
Janusz
> > + "lockdep loop preventive failure possibly
> > occurred\n");
>
> s/possibly occurred//
>
> It's taken for granted that we don't know exactly why the kernel
> rejected the call (though if we had tracefs hooked up, we should be
> including that information there) just that it falls under our
> blanket
> incompatible device errno.
>
> > + igt_assert(map);
>
> Ok, looks future proof.
>
> > + /* set object pages in order to activate MMU notifier for
> > it */
> > + gem_set_domain(fd, handle, t->domain, t->domain);
>
> I would suggest (a variant?) that also attached a igt_spin_t to the
> userptr,
> waited for it to start executing, call igt_spin_set_timeout and then
> do
> the munmap.
>
> > + /* trigger the notifier */
> > + munmap(ptr, PAGE_SIZE);
> > +
> > + /* cleanup */
> > + munmap(map, PAGE_SIZE);
> > + gem_close(fd, handle);
> > +}
>
> Reviewed-by: Chris Wilson
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > reconfiguring global resources).
> > >
> > > But in nonblocking mode userspace has then no idea this happened,
> > > which can lead to spurious EBUSY calls, both:
> > > - when that other CRTC is currently busy doing a page_flip the
> > > ALLOW_MODESET commit can fail with an EBUSY
> > > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > > of the additional commit inserted by the kernel without userspace's
> > > knowledge
> > >
> > > For blocking commits this isn't a problem, because everyone else will
> > > just block until all the CRTC are reconfigured. Only thing userspace
> > > can notice is the dropped frames without any reason for why frames got
> > > dropped.
> > >
> > > Consensus is that we need new uapi to handle this properly, but no one
> > > has any idea what exactly the new uapi should look like. As a stop-gap
> > > plug this problem by demoting nonblocking commits which might cause
> > > issues by including CRTCs not in the original request to blocking
> > > commits.
> > >
> > > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > > don't want to silently convert page flips into blocking plane updates
> > > just because the driver is buggy.
> > >
> > > v3: Fix inverted WARN_ON (Pekka).
> > >
> > > References:
> > > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > > Bugzilla:
> > > https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > > Cc: Daniel Stone
> > > Cc: Pekka Paalanen
> > > Cc: sta...@vger.kernel.org
> > > Reviewed-by: Daniel Stone
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 9ccfbf213d72..4c035abf98b8 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > {
> > > struct drm_mode_config *config = >dev->mode_config;
> > > - int ret;
> > > + unsigned requested_crtc = 0;
> > > + unsigned affected_crtc = 0;
> > > + struct drm_crtc *crtc;
> > > + struct drm_crtc_state *crtc_state;
> > > + bool nonblocking = true;
> > > + int ret, i;
> > > +
> > > + /*
> > > + * For commits that allow modesets drivers can add other CRTCs to
> > > the
> > > + * atomic commit, e.g. when they need to reallocate global
> > > resources.
> > > + *
> > > + * But when userspace also requests a nonblocking commit then
> > > userspace
> > > + * cannot know that the commit affects other CRTCs, which can
> > > result in
> > > + * spurious EBUSY failures. Until we have better uapi plug this by
> > > + * demoting such commits to blocking mode.
> > > + */
> > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > + requested_crtc |= drm_crtc_mask(crtc);
> > >
> > > ret = drm_atomic_check_only(state);
> > > if (ret)
> > > return ret;
> > >
> > > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > + affected_crtc |= drm_crtc_mask(crtc);
> > > +
> > > + if (affected_crtc != requested_crtc) {
> > > + /* adding other CRTC is only allowed for modeset commits */
> > > + WARN_ON(!state->allow_modeset);
> >
> > Not sure that's really true. What if the driver needs to eg.
> > redistribute FIFO space or something between the pipes? Or do we
> > expect drivers to now examine state->allow_modeset to figure out
> > if they're allowed to do certain things?
>
> Maybe we need more fine-grained flags here, but adding other states
> (and blocking a commit flow) is exactly the uapi headaches this patch
> tries to solve here. So if our driver currently adds crtc states to
> reallocate fifo between pipes for an atomic flip then yes we're
> breaking userspace. Well, everyone figured out by now that you get
> random EBUSY and dropped frames for no apparent reason at all, and
> work around it. But happy, they are not.
I don't think we do this currently for the FIFO, but in theory we
could.
The one thing we might do currently is cdclk reprogramming, but that
can only happen without a full modeset when there's only a single
active pipe. So we shouldn't hit this right now. But that restriction
is going to disappear in the future, at which point we may want to
do
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Mark up the racy use of perf->exclusive_stream
== Series Details ==
Series: drm/i915/perf: Mark up the racy use of perf->exclusive_stream
URL : https://patchwork.freedesktop.org/series/73905/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8004 -> Patchwork_16703
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16703/index.html
Known issues
Here are the changes found in Patchwork_16703 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [PASS][1] -> [FAIL][2] ([CI#94])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16703/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [PASS][3] -> [DMESG-FAIL][4] ([i915#877])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16703/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@vgem_basic@dmabuf-export:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([CI#94] / [i915#402])
+1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16703/fi-tgl-y/igt@vgem_ba...@dmabuf-export.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-icl-y: [INCOMPLETE][7] ([i915#140]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-y/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16703/fi-icl-y/igt@i915_selftest@live_execlists.html
* igt@kms_addfb_basic@addfb25-bad-modifier:
- fi-tgl-y: [DMESG-WARN][9] ([CI#94] / [i915#402]) -> [PASS][10]
+1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16703/fi-tgl-y/igt@kms_addfb_ba...@addfb25-bad-modifier.html
* igt@kms_chamelium@dp-edid-read:
- fi-cml-u2: [FAIL][11] ([i915#217] / [i915#976]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16703/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#140]: https://gitlab.freedesktop.org/drm/intel/issues/140
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976
Participating hosts (43 -> 43)
--
Additional (8): fi-ehl-1 fi-skl-6770hq fi-ilk-650 fi-snb-2520m fi-gdg-551
fi-elk-e7500 fi-blb-e6850 fi-skl-6600u
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-byt-squawks
fi-byt-clapper fi-bsw-nick fi-bdw-samus fi-snb-2600
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8004 -> Patchwork_16703
CI-20190529: 20190529
CI_DRM_8004: 1a2e0cce5af4a9ad9694995610ed64578ccc430f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5464: 8cf2f8684992052ab89de1cf328c418224c0c2a7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16703: 0dd2fa1856167d951facb19c40185fb2929cf67d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0dd2fa185616 drm/i915/perf: Mark up the racy use of perf->exclusive_stream
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16703/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm: Nuke mode->vrefresh
On 25.02.2020 12:21, Ville Syrjälä wrote:
> On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote:
>> On 19.02.2020 21:35, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> Get rid of mode->vrefresh and just calculate it on demand. Saves
>>> a bit of space and avoids the cached value getting out of sync
>>> with reality.
>>>
>>> Mostly done with cocci, with the following manual fixups:
>>> - Remove the now empty loop in drm_helper_probe_single_connector_modes()
>>> - Fix __MODE() macro in ch7006_mode.c
>>> - Fix DRM_MODE_ARG() macro in drm_modes.h
>>> - Remove leftover comment from samsung_s6d16d0_mode
>> ...
>>> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
>>> b/drivers/gpu/drm/panel/panel-arm-versatile.c
>>> index 41444a73c980..47b37fef7ee8 100644
>>> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
>>> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
>>> @@ -143,7 +143,6 @@ static const struct versatile_panel_type
>>> versatile_panels[] = {
>>> .vsync_start = 240 + 5,
>>> .vsync_end = 240 + 5 + 6,
>>> .vtotal = 240 + 5 + 6 + 5,
>>> - .vrefresh = 116,
>>
>> Are you sure vrefresh calculated (from totals and clock) is different
>> than this field? If not, we risk regressions.
>>
>> This case is OK, but there is plenty other cases.
> IIRC I did spot check a few of them. But which code exactly do you think
> is abusing vrefresh and thus could break?
I guess suspect/potential victim is every code which uses
drm_mode_vrefresh - after this patch the function can return different
value(if there are differences between provided and calculated vrefresh).
Quick examples where output of this function matters:
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c#L387
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c#L42
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/tilcdc/tilcdc_crtc.c#L810
Regards
Andrzej
>
>>
>> Regards
>>
>> Andrzej
>>
>>
>>> .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
>>> },
>>> },
>>> @@ -167,7 +166,6 @@ static const struct versatile_panel_type
>>> versatile_panels[] = {
>>> .vsync_start = 480 + 11,
>>> .vsync_end = 480 + 11 + 2,
>>> .vtotal = 480 + 11 + 2 + 32,
>>> - .vrefresh = 60,
>>> .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
>>> },
>>> },
>>> @@ -190,7 +188,6 @@ static const struct versatile_panel_type
>>> versatile_panels[] = {
>>> .vsync_start = 220 + 0,
>>> .vsync_end = 220 + 0 + 2,
>>> .vtotal = 220 + 0 + 2 + 1,
>>> - .vrefresh = 390,
>>> .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
>>> },
>>> .bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
>>> @@ -214,7 +211,6 @@ static const struct versatile_panel_type
>>> versatile_panels[] = {
>>> .vsync_start = 320 + 2,
>>> .vsync_end = 320 + 2 + 2,
>>> .vtotal = 320 + 2 + 2 + 2,
>>> - .vrefresh = 116,
>>> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
>>> },
>>> .bus_flags = DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
>>> diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
>>> b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
>>> index 74d58ee7d04c..7c27bd5e3486 100644
>>> --- a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
>>> +++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
>>> @@ -229,7 +229,7 @@ static int boe_panel_get_modes(struct drm_panel *panel,
>>> mode = drm_mode_duplicate(connector->dev, m);
>>> if (!mode) {
>>> DRM_DEV_ERROR(pinfo->base.dev, "failed to add mode %ux%u@%u\n",
>>> - m->hdisplay, m->vdisplay, m->vrefresh);
>>> + m->hdisplay, m->vdisplay, drm_mode_vrefresh(m));
>>> return -ENOMEM;
>>> }
>>>
>>> @@ -262,7 +262,6 @@ static const struct drm_display_mode
>>> default_display_mode = {
>>> .vsync_start = 1920 + 10,
>>> .vsync_end = 1920 + 10 + 14,
>>> .vtotal = 1920 + 10 + 14 + 4,
>>> - .vrefresh = 60,
>>> };
>>>
>>> /* 8 inch */
>>> diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
>>> b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
>>> index 48a164257d18..c580bd1e121c 100644
>>> --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
>>> +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
>>> @@ -594,7 +594,6 @@ static const struct drm_display_mode
>>> boe_tv101wum_nl6_default_mode = {
>>> .vsync_start = 1920 + 10,
>>> .vsync_end = 1920 + 10 + 14,
>>> .vtotal = 1920 + 10 + 14 + 4,
>>> - .vrefresh = 60,
>>> };
>>>
>>> static const struct panel_desc
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> > ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > of the additional commit inserted by the kernel without userspace's
> > knowledge
> >
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> >
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. As a stop-gap
> > plug this problem by demoting nonblocking commits which might cause
> > issues by including CRTCs not in the original request to blocking
> > commits.
> >
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> >
> > v3: Fix inverted WARN_ON (Pekka).
> >
> > References:
> > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > Cc: Daniel Stone
> > Cc: Pekka Paalanen
> > Cc: sta...@vger.kernel.org
> > Reviewed-by: Daniel Stone
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > 1 file changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 9ccfbf213d72..4c035abf98b8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > {
> > struct drm_mode_config *config = >dev->mode_config;
> > - int ret;
> > + unsigned requested_crtc = 0;
> > + unsigned affected_crtc = 0;
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *crtc_state;
> > + bool nonblocking = true;
> > + int ret, i;
> > +
> > + /*
> > + * For commits that allow modesets drivers can add other CRTCs to the
> > + * atomic commit, e.g. when they need to reallocate global resources.
> > + *
> > + * But when userspace also requests a nonblocking commit then
> > userspace
> > + * cannot know that the commit affects other CRTCs, which can result
> > in
> > + * spurious EBUSY failures. Until we have better uapi plug this by
> > + * demoting such commits to blocking mode.
> > + */
> > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > + requested_crtc |= drm_crtc_mask(crtc);
> >
> > ret = drm_atomic_check_only(state);
> > if (ret)
> > return ret;
> >
> > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > + affected_crtc |= drm_crtc_mask(crtc);
> > +
> > + if (affected_crtc != requested_crtc) {
> > + /* adding other CRTC is only allowed for modeset commits */
> > + WARN_ON(!state->allow_modeset);
>
> Not sure that's really true. What if the driver needs to eg.
> redistribute FIFO space or something between the pipes? Or do we
> expect drivers to now examine state->allow_modeset to figure out
> if they're allowed to do certain things?
Maybe we need more fine-grained flags here, but adding other states
(and blocking a commit flow) is exactly the uapi headaches this patch
tries to solve here. So if our driver currently adds crtc states to
reallocate fifo between pipes for an atomic flip then yes we're
breaking userspace. Well, everyone figured out by now that you get
random EBUSY and dropped frames for no apparent reason at all, and
work around it. But happy, they are not.
Also we've already crossed that bridge a bit with mucking around with
allow_modeset from driver code with the self refresh helpers.
Cheers, Daniel
>
> > +
> > + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid
> > EBUSY\n", state);
> > + nonblocking = false;
> > + } else {
> > + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > + }
> >
> > - return config->funcs->atomic_commit(state->dev, state, true);
> > + return config->funcs->atomic_commit(state->dev, state, nonblocking);
> > }
> > EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
> >
> > --
> >
Re: [Intel-gfx] [PATCH v3 4/7] drm/i915: Fix wrongly populated plane possible_crtcs bit mask
On Mon, Feb 24, 2020 at 06:10:01PM +0530, Anshuman Gupta wrote:
> As a disabled pipe in pipe_mask is not having a valid intel crtc,
> driver wrongly populates the possible_crtcs mask while initializing
> the plane for a CRTC. Fixing up the plane possible_crtcs mask.
>
> changes since RFC:
> - Simplify the possible_crtcs initialization. [Ville]
> v2:
> - Removed the unnecessary stack garbage possible_crtcs to
> drm_universal_plane_init. [Ville]
> v3:
> - Combine the intel_crtc assignment and declaration. [Ville]
>
> Cc: Ville Syrjälä
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 13 +
> drivers/gpu/drm/i915/display/intel_sprite.c | 5 +
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index aacbdc47fcea..41a0f2e9b6b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16628,6 +16628,18 @@ static void intel_crtc_free(struct intel_crtc *crtc)
> kfree(crtc);
> }
>
> +static void intel_plane_possible_crtcs_init(struct drm_i915_private
> *dev_priv)
> +{
> + struct intel_plane *plane;
> +
> + for_each_intel_plane(_priv->drm, plane) {
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
> + plane->pipe);
> +
> + plane->base.possible_crtcs = drm_crtc_mask(>base);
> + }
> +}
> +
> static int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe)
> {
> struct intel_plane *primary, *cursor;
> @@ -17843,6 +17855,7 @@ int intel_modeset_init(struct drm_i915_private *i915)
> }
> }
>
> + intel_plane_possible_crtcs_init(i915);
> intel_shared_dpll_init(dev);
> intel_update_fdi_pll_freq(i915);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 7abeefe8dce5..b5c7b271a1a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -3011,7 +3011,6 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> struct intel_plane *plane;
> enum drm_plane_type plane_type;
> unsigned int supported_rotations;
> - unsigned int possible_crtcs;
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> @@ -3066,10 +3065,8 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> else
> plane_type = DRM_PLANE_TYPE_OVERLAY;
>
> - possible_crtcs = BIT(pipe);
> -
> ret = drm_universal_plane_init(_priv->drm, >base,
> -possible_crtcs, plane_funcs,
> +0, plane_funcs,
> formats, num_formats, modifiers,
> plane_type,
> "plane %d%c", plane_id + 1,
Looks like you missed all the other places that do this:
intel_primary_plane_create(), intel_sprite_plane_create(),
intel_cursor_plane_create().
Apart from that everything in the series looks ready.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH][next] drm: Replace zero-length array with flexible-array member
Quoting Gustavo A. R. Silva (2020-02-25 14:03:47) > The current codebase makes use of the zero-length array language > extension to the C90 standard, but the preferred mechanism to declare > variable-length types such as these ones is a flexible array member[1][2], > introduced in C99: I remember when gcc didn't support []. For the record, it appears support for flexible arrays landed in gcc-3.0. So passes the minimum compiler spec. That would be useful to mention for old farts with forgetful memories. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v18 7/8] drm/i915: Restrict qgv points which don't have enough bandwidth.
According to BSpec 53998, we should try to restrict qgv points, which can't provide enough bandwidth for desired display configuration. Currently we are just comparing against all of those and take minimum(worst case). v2: Fixed wrong PCode reply mask, removed hardcoded values. v3: Forbid simultaneous legacy SAGV PCode requests and restricting qgv points. Put the actual restriction to commit function, added serialization(thanks to Ville) to prevent commit being applied out of order in case of nonblocking and/or nomodeset commits. v4: - Minor code refactoring, fixed few typos(thanks to James Ausmus) - Change the naming of qgv point masking/unmasking functions(James Ausmus). - Simplify the masking/unmasking operation itself, as we don't need to mask only single point per request(James Ausmus) - Reject and stick to highest bandwidth point if SAGV can't be enabled(BSpec) v5: - Add new mailbox reply codes, which seems to happen during boot time for TGL and indicate that QGV setting is not yet available. v6: - Increase number of supported QGV points to be in sync with BSpec. v7: - Rebased and resolved conflict to fix build failure. - Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus) v8: - Don't report an error if we can't restrict qgv points, as SAGV can be disabled by BIOS, which is completely legal. So don't make CI panic. Instead if we detect that there is only 1 QGV point accessible just analyze if we can fit the required bandwidth requirements, but no need in restricting. v9: - Fix wrong QGV transition if we have 0 planes and no SAGV simultaneously. v10: - Fix CDCLK corruption, because of global state getting serialized without modeset, which caused copying of non-calculated cdclk to be copied to dev_priv(thanks to Ville for the hint). v11: - Remove unneeded headers and spaces(Matthew Roper) - Remove unneeded intel_qgv_info qi struct from bw check and zero out the needed one(Matthew Roper) - Changed QGV error message to have more clear meaning(Matthew Roper) - Use state->modeset_set instead of any_ms(Matthew Roper) - Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used - Keep using crtc_state->hw.active instead of .enable(Matthew Roper) - Moved unrelated changes to other patch(using latency as parameter for plane wm calculation, moved to SAGV refactoring patch) v12: - Fix rebase conflict with own temporary SAGV/QGV fix. - Remove unnecessary mask being zero check when unmasking qgv points as this is completely legal(Matt Roper) - Check if we are setting the same mask as already being set in hardware to prevent error from PCode. - Fix error message when restricting/unrestricting qgv points to "mask/unmask" which sounds more accurate(Matt Roper) - Move sagv status setting to icl_get_bw_info from atomic check as this should be calculated only once.(Matt Roper) - Edited comments for the case when we can't enable SAGV and use only 1 QGV point with highest bandwidth to be more understandable.(Matt Roper) v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä) - Changed comment for zero new_mask in qgv points masking function to better reflect reality(Ville Syrjälä) - Simplified bit mask operation in qgv points masking function (Ville Syrjälä) - Moved intel_qgv_points_mask closer to gen11 SAGV disabling, however this still can't be under modeset condition(Ville Syrjälä) - Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask (Ville Syrjälä) - Extracted PCode changes to separate patch.(Ville Syrjälä) - Now treat num_planes 0 same as 1 to avoid confusion and returning max_bw as 0, which would prevent choosing QGV point having max bandwidth in case if SAGV is not allowed, as per BSpec(Ville Syrjälä) - Do the actual qgv_points_mask swap in the same place as all other global state parts like cdclk are swapped. In the next patch, this all will be moved to bw state as global state, once new global state patch series from Ville lands v14: - Now using global state to serialize access to qgv points - Added global state locking back, otherwise we seem to read bw state in a wrong way. v15: - Added TODO comment for near atomic global state locking in bw code. v16: - Fixed intel_atomic_bw_* functions to be intel_bw_* as discussed with Jani Nikula. - Take bw_state_changed flag into use. Signed-off-by: Stanislav Lisovskiy Cc: Ville Syrjälä Cc: James Ausmus --- drivers/gpu/drm/i915/display/intel_bw.c | 184 +-- drivers/gpu/drm/i915/display/intel_bw.h | 9 + drivers/gpu/drm/i915/display/intel_display.c | 125 - drivers/gpu/drm/i915/i915_drv.h
Re: [Intel-gfx] [PATCH 03/51] drm: add managed resources tied to drm_device
On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote:
>
> Hi Daniel,
>
>
> The patchset looks interesting.
>
>
> On 21.02.2020 22:02, Daniel Vetter wrote:
> > We have lots of these. And the cleanup code tends to be of dubious
> > quality. The biggest wrong pattern is that developers use devm_, which
> > ties the release action to the underlying struct device, whereas
> > all the userspace visible stuff attached to a drm_device can long
> > outlive that one (e.g. after a hotunplug while userspace has open
> > files and mmap'ed buffers). Give people what they want, but with more
> > correctness.
>
>
> I am not familiar with this stuff, so forgive me stupid questions.
>
> Is it documented how uapi should behave in such case?
>
> I guess the general rule is to return errors on most ioctls (ENODEV,
> EIO?), and wait until userspace releases everything, as there is not
> much more to do.
>
> If that is true what is the point of keeping these structs anyway -
> trivial functions with small context data should do the job.
>
> I suspect I am missing something but I do not know what :)
We could do the above (also needs unmapping of all mmaps, so userspace
then gets SIGSEGV everywhere) and watch userspace crash
Essentially if the kernel can't do this properly, then there's no hope
that userspace will be any better.
Hence the idea is that we keep everything userspace facing still
around, except it doesn't do much anymore. So connectors still there,
but they look disconnected. Userspace can then hopefully eventually
get around to processing the sysfs hotunplug event and remove the
device from all its list. So the long-term idea is that a lot of stuff
keeps working, except the driver doesn't talk to the hardware anymore.
And we just sit around waiting for userspace to clean things up.
I guess once we have a bunch of the panel/usb drivers converted over
we could indeed document how this is all supposed to work from an uapi
pov. But right now a lot of this is all rather aspirational, I think
only the recent simple display pipe based drivers implement this as
described above.
> > Mostly copied from devres.c, with types adjusted to fit drm_device and
> > a few simplifications - I didn't (yet) copy over everything. Since
> > the types don't match code sharing looked like a hopeless endeavour.
> >
> > For now it's only super simplified, no groups, you can't remove
> > actions (but kfree exists, we'll need that soon). Plus all specific to
> > drm_device ofc, including the logging. Which I didn't bother to make
> > compile-time optional, since none of the other drm logging is compile
> > time optional either.
>
>
> I saw in v1 thread that copy/paste is OK and merging back devres and
> drmres can be done later, but experience shows that after short time
> things get de-synchronized and merging process becomes quite painful.
>
> On the other side I guess it shouldn't be difficult to split devres into
> consumer agnostic core and "struct device" helpers and then use the core
> in drm.
>
> For example currently devres uses two fields from struct device:
>
> spinlock_tdevres_lock;
> struct list_headdevres_head;
>
> Lets put it into separate struct:
>
> struct devres {
>
> spinlock_tlock;
> struct list_headhead;
>
> };
>
> And embed this struct into "struct device".
>
> Then convert all core devres functions to take "struct devres *"
> argument instead of "struct device *" and then these core functions can
> be usable in drm.
>
> Looks quite simple separation of abstraction (devres) and its consumer
> (struct device).
>
> After such split one could think about changing name devres to something
> more reliable.
There was a long discussion on v1 exactly about this, Greg's
suggestion was to "just share a struct device". So we're not going to
do this here, and the struct device seems like slight overkill and not
a good enough fit here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v18 5/8] drm/i915: Refactor intel_can_enable_sagv
Currently intel_can_enable_sagv function contains a mix of workarounds for different platforms some of them are not valid for gens >= 11 already, so lets split it into separate functions. v2: - Rework watermark calculation algorithm to attempt to calculate Level 0 watermark with added sagv block time latency and check if it fits in DBuf in order to determine if SAGV can be enabled already at this stage, just as BSpec 49325 states. if that fails rollback to usual Level 0 latency and disable SAGV. - Remove unneeded tabs(James Ausmus) v3: Rebased the patch v4: - Added back interlaced check for Gen12 and added separate function for TGL SAGV check (thanks to James Ausmus for spotting) - Removed unneeded gen check - Extracted Gen12 SAGV decision making code to a separate function from skl_compute_wm v5: - Added SAGV global state to dev_priv, because we need to track all pipes, not only those in atomic state. Each pipe has now correspondent bit mask reflecting, whether it can tolerate SAGV or not(thanks to Ville Syrjala for suggestions). - Now using active flag instead of enable in crc usage check. v6: - Fixed rebase conflicts v7: - kms_cursor_legacy seems to get broken because of multiple memcpy calls when copying level 0 water marks for enabled SAGV, to fix this now simply using that field right away, without copying, for that introduced a new wm_level accessor which decides which wm_level to return based on SAGV state. v8: - Protect crtc_sagv_mask same way as we do for other global state changes: i.e check if changes are needed, then grab all crtc locks to serialize the changes(Ville Syrjälä) - Add crtc_sagv_mask caching in order to avoid needless recalculations (Matthew Roper) - Put back Gen12 SAGV switch in order to get it enabled in separate patch(Matthew Roper) - Rename *_set_sagv_mask to *_compute_sagv_mask(Matthew Roper) - Check if there are no active pipes in intel_can_enable_sagv instead of platform specific functions(Matthew Roper), same for intel_has_sagv check. v9 - Switched to u8 for crtc_sagv_mask(Ville Syrjälä) - crtc_sagv_mask now is pipe_sagv_mask(Ville Syrjälä) - Extracted sagv checking logic from skl/icl/tgl_compute_sagv_mask - Extracted skl_plane_wm_level function and passing latency to separate patches(Ville Syrjälä) - Removed part of unneeded copy-paste from tgl_check_pipe_fits_sagv_wm (Ville Syrjälä) - Now using simple assignment for sagv_wm0 as it contains only pod types and no pointers(Ville Syrjälä) - Fixed intel_can_enable_sagv not to do double duty, now it only check SAGV bits by ANDing those between local and global state. The SAGV masks are now computed after watermarks are available, in order to be able to figure out if ddb ranges are fitting nicely. (Ville Syrjälä) - Now having uv_sagv_wm0 and sagv_wm0, otherwise we have wrong logic when using skl_plane_wm_level accessor, as we had previously for Gen11+ color plane and regular wm levels, so probably both has to be recalculated with additional SAGV block time for Level 0. v10: - Starting to use new global state for storing pipe_sagv_mask v11: - Fixed rebase conflict with recent drm-tip - Check if we really need to recalculate SAGV mask, otherwise bail out without making any changes. - Use cached SAGV result, instead of recalculating it everytime, if bw_state hasn't changed. v12: - Removed WARN from intel_can_enable_sagv, in some of the commits if we don't recalculated watermarks, bw_state is not recalculated, thus leading to SAGV state not recalculated by the commit state, which is still calling intel_can_enable_sagv function. Fix that by just analyzing the current global bw_state object - because we simply have no other objects related to that. v13: - Rebased, fixed warnings regarding long lines - Changed function call sites from intel_atomic_bw* to intel_wb_* as was suggested.(Jani Nikula) - Taken ddb_state_changed and bw_state_changed into use. v14: - total_affected_planes is no longer needed to check for ddb changes, just as active_pipe_changes. Signed-off-by: Stanislav Lisovskiy Cc: Ville Syrjälä Cc: James Ausmus --- drivers/gpu/drm/i915/display/intel_bw.h | 18 + drivers/gpu/drm/i915/display/intel_display.c | 27 +- .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/intel_pm.c | 428 -- drivers/gpu/drm/i915/intel_pm.h | 4 +- 5 files changed, 437 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h index b5f61463922f..c32b5285c12f 100644 --- a/drivers/gpu/drm/i915/display/intel_bw.h +++
[Intel-gfx] [PATCH v18 4/8] drm/i915: Introduce more *_state_changed indicators
The reasoning behind this is such that current dependencies
in the code are rather implicit in a sense, we have to constantly
check a bunch of different bits like state->modeset,
state->active_pipe_changes, which sometimes can indicate counter
intuitive changes.
By introducing more fine grained state change tracking we achieve
better readability and dependency maintenance for the code.
For example it is no longer needed to evaluate active_pipe_changes
to understand if there were changes for wm/ddb - lets just have
a correspondent bit in a state, called ddb_state_changed.
active_pipe_changes just indicate whether there was some pipe added
or removed. Then we evaluate if wm/ddb had been changed.
Same for sagv/bw state. ddb changes may or may not affect if out
bandwidth constraints have been changed.
v2: Add support for older Gens in order not to introduce regressions
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_atomic.c | 2 ++
drivers/gpu/drm/i915/display/intel_bw.c | 28 ++--
drivers/gpu/drm/i915/display/intel_display.c | 16 ++
.../drm/i915/display/intel_display_types.h| 32 ---
drivers/gpu/drm/i915/intel_pm.c | 5 ++-
5 files changed, 62 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index d043057d2fa0..0db9c66d3c0f 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -525,6 +525,8 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
state->dpll_set = state->modeset = false;
state->global_state_changed = false;
state->active_pipes = 0;
+ state->ddb_state_changed = false;
+ state->bw_state_changed = false;
}
struct intel_crtc_state *
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index bdad7476dc7b..d5be603b8b03 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -424,9 +424,27 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
struct intel_crtc *crtc;
int i, ret;
- /* FIXME earlier gens need some checks too */
- if (INTEL_GEN(dev_priv) < 11)
+ /*
+* For earlier Gens let's consider bandwidth changed if ddb
requirements,
+* has been changed.
+*/
+ if (INTEL_GEN(dev_priv) < 11) {
+ if (state->ddb_state_changed) {
+ bw_state = intel_bw_get_state(state);
+ if (IS_ERR(bw_state))
+ return PTR_ERR(bw_state);
+
+ ret = intel_atomic_lock_global_state(_state->base);
+ if (ret)
+ return ret;
+
+ DRM_DEBUG_KMS("Marking bw state changed for atomic
state %p\n",
+ state);
+
+ state->bw_state_changed = true;
+ }
return 0;
+ }
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -447,7 +465,7 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
old_active_planes == new_active_planes)
continue;
- bw_state = intel_bw_get_state(state);
+ bw_state = intel_bw_get_state(state);
if (IS_ERR(bw_state))
return PTR_ERR(bw_state);
@@ -468,6 +486,10 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
if (ret)
return ret;
+ DRM_DEBUG_KMS("Marking bw state changed for atomic state %p\n", state);
+
+ state->bw_state_changed = true;
+
data_rate = intel_bw_data_rate(dev_priv, bw_state);
num_active_planes = intel_bw_num_active_planes(dev_priv, bw_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3031e64ee518..137fb645097a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15540,8 +15540,10 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
* SKL workaround: bspec recommends we disable the SAGV when we
* have more then one pipe enabled
*/
- if (!intel_can_enable_sagv(state))
- intel_disable_sagv(dev_priv);
+ if (state->bw_state_changed) {
+ if (!intel_can_enable_sagv(state))
+ intel_disable_sagv(dev_priv);
+ }
intel_modeset_verify_disabled(dev_priv, state);
}
@@ -15565,7 +15567,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: Mark up the racy use of perf->exclusive_stream
== Series Details == Series: drm/i915/perf: Mark up the racy use of perf->exclusive_stream URL : https://patchwork.freedesktop.org/series/73905/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0dd2fa185616 drm/i915/perf: Mark up the racy use of perf->exclusive_stream -:11: WARNING:TYPO_SPELLING: 'avaiable' may be misspelled - perhaps 'available'? #11: as not avaiable. This should ensure that there are no more concurrent total: 0 errors, 1 warnings, 0 checks, 41 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH][next] drm: Replace zero-length array with flexible-array member
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 +-
drivers/gpu/drm/gma500/intel_bios.h | 2 +-
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.h | 2 +-
drivers/gpu/drm/msm/msm_gem.h | 2 +-
drivers/gpu/drm/qxl/qxl_cmd.c | 2 +-
drivers/gpu/drm/vboxvideo/vboxvideo.h | 2 +-
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
include/drm/bridge/mhl.h | 4 ++--
include/drm/drm_displayid.h | 2 +-
include/uapi/drm/i915_drm.h | 4 ++--
14 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index 6b68fe16041b..98e60df882b6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -105,7 +105,7 @@ struct etnaviv_gem_submit {
unsigned int nr_pmrs;
struct etnaviv_perfmon_request *pmrs;
unsigned int nr_bos;
- struct etnaviv_gem_submit_bo bos[0];
+ struct etnaviv_gem_submit_bo bos[];
/* No new members here, the previous one is variable-length! */
};
diff --git a/drivers/gpu/drm/gma500/intel_bios.h
b/drivers/gpu/drm/gma500/intel_bios.h
index a1f9ce9465a5..0e6facf21e33 100644
--- a/drivers/gpu/drm/gma500/intel_bios.h
+++ b/drivers/gpu/drm/gma500/intel_bios.h
@@ -227,7 +227,7 @@ struct bdb_general_definitions {
* number = (block_size - sizeof(bdb_general_definitions))/
* sizeof(child_device_config);
*/
- struct child_device_config devices[0];
+ struct child_device_config devices[];
};
struct bdb_lvds_options {
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 05c7cbe32eb4..aef7fe932d1a 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -462,7 +462,7 @@ struct bdb_general_definitions {
* number = (block_size - sizeof(bdb_general_definitions))/
* defs->child_dev_size;
*/
- u8 devices[0];
+ u8 devices[];
} __packed;
/*
@@ -839,7 +839,7 @@ struct bdb_mipi_config {
struct bdb_mipi_sequence {
u8 version;
- u8 data[0]; /* up to 6 variable length blocks */
+ u8 data[]; /* up to 6 variable length blocks */
} __packed;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 47561dc29304..5cec79152f17 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -216,7 +216,7 @@ struct virtual_engine {
/* And finally, which physical engines this virtual engine maps onto. */
unsigned int num_siblings;
- struct intel_engine_cs *siblings[0];
+ struct intel_engine_cs *siblings[];
};
static struct virtual_engine *to_virtual_engine(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 0d1f6c8ff355..5a6561f7a210 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -42,7 +42,7 @@ struct i915_vma_coredump {
int num_pages;
int page_count;
int unused;
- u32 *pages[0];
+ u32 *pages[];
};
struct i915_request_coredump {
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 9e0953c2b7ce..37aa556c5f92 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -157,7 +157,7 @@ struct msm_gem_submit {
uint32_t handle;
};
uint64_t iova;
- } bos[0];
+ }
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
> ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
> of the additional commit inserted by the kernel without userspace's
> knowledge
>
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
>
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. As a stop-gap
> plug this problem by demoting nonblocking commits which might cause
> issues by including CRTCs not in the original request to blocking
> commits.
>
> v2: Add comments and a WARN_ON to enforce this only when allowed - we
> don't want to silently convert page flips into blocking plane updates
> just because the driver is buggy.
>
> v3: Fix inverted WARN_ON (Pekka).
>
> References:
> https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> Cc: Daniel Stone
> Cc: Pekka Paalanen
> Cc: sta...@vger.kernel.org
> Reviewed-by: Daniel Stone
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 34 +++---
> 1 file changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9ccfbf213d72..4c035abf98b8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> {
> struct drm_mode_config *config = >dev->mode_config;
> - int ret;
> + unsigned requested_crtc = 0;
> + unsigned affected_crtc = 0;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + bool nonblocking = true;
> + int ret, i;
> +
> + /*
> + * For commits that allow modesets drivers can add other CRTCs to the
> + * atomic commit, e.g. when they need to reallocate global resources.
> + *
> + * But when userspace also requests a nonblocking commit then userspace
> + * cannot know that the commit affects other CRTCs, which can result in
> + * spurious EBUSY failures. Until we have better uapi plug this by
> + * demoting such commits to blocking mode.
> + */
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + requested_crtc |= drm_crtc_mask(crtc);
>
> ret = drm_atomic_check_only(state);
> if (ret)
> return ret;
>
> - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + if (affected_crtc != requested_crtc) {
> + /* adding other CRTC is only allowed for modeset commits */
> + WARN_ON(!state->allow_modeset);
Not sure that's really true. What if the driver needs to eg.
redistribute FIFO space or something between the pipes? Or do we
expect drivers to now examine state->allow_modeset to figure out
if they're allowed to do certain things?
> +
> + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid
> EBUSY\n", state);
> + nonblocking = false;
> + } else {
> + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> + }
>
> - return config->funcs->atomic_commit(state->dev, state, true);
> + return config->funcs->atomic_commit(state->dev, state, nonblocking);
> }
> EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
>
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/20] drm/i915: Use ww pinning for intel_context_create_request()
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index c5dc714958f2..9e9da6dbb592 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -440,15 +440,25 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
struct i915_request *intel_context_create_request(struct intel_context *ce)
{
+ struct i915_gem_ww_ctx ww;
struct i915_request *rq;
int err;
- err = intel_context_pin(ce);
- if (unlikely(err))
- return ERR_PTR(err);
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = intel_context_pin_ww(ce, );
+ if (!err) {
+ rq = i915_request_create(ce);
+ intel_context_unpin(ce);
+ } else if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ } else {
+ rq = ERR_PTR(err);
+ }
- rq = i915_request_create(ce);
- intel_context_unpin(ce);
+ i915_gem_ww_ctx_fini();
if (IS_ERR(rq))
return rq;
--
2.25.0.24.g3f081b084b0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/20] drm/i915: Convert i915_perf to ww locking as well
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_perf.c | 57 +++-
1 file changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e34c79df6ebc..5f7094ff738a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1242,24 +1242,39 @@ static struct intel_context *oa_pin_context(struct
i915_perf_stream *stream)
struct i915_gem_engines_iter it;
struct i915_gem_context *ctx = stream->ctx;
struct intel_context *ce;
- int err;
+ struct i915_gem_ww_ctx ww;
+ int err = -ENODEV;
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
if (ce->engine != stream->engine) /* first match! */
continue;
- /*
-* As the ID is the gtt offset of the context's vma we
-* pin the vma to ensure the ID remains fixed.
-*/
- err = intel_context_pin(ce);
- if (err == 0) {
- stream->pinned_ctx = ce;
- break;
- }
+ err = 0;
+ break;
}
i915_gem_context_unlock_engines(ctx);
+ if (err)
+ return ERR_PTR(err);
+
+ i915_gem_ww_ctx_init(, true);
+retry:
+ /*
+* As the ID is the gtt offset of the context's vma we
+* pin the vma to ensure the ID remains fixed.
+*/
+ err = intel_context_pin_ww(ce, );
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+
+ if (err)
+ return ERR_PTR(err);
+
+ stream->pinned_ctx = ce;
return stream->pinned_ctx;
}
@@ -1976,15 +1991,22 @@ static int emit_oa_config(struct i915_perf_stream
*stream,
{
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
int err;
vma = get_oa_vma(stream, oa_config);
if (IS_ERR(vma))
return PTR_ERR(vma);
- err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = i915_gem_object_lock(vma->obj, );
if (err)
- goto err_vma_put;
+ goto err;
+
+ err = i915_vma_pin_ww(vma, , 0, 0, PIN_GLOBAL | PIN_HIGH);
+ if (err)
+ goto err;
intel_engine_pm_get(ce->engine);
rq = i915_request_create(ce);
@@ -1994,11 +2016,9 @@ static int emit_oa_config(struct i915_perf_stream
*stream,
goto err_vma_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, 0);
if (!err)
err = i915_vma_move_to_active(vma, rq, 0);
- i915_vma_unlock(vma);
if (err)
goto err_add_request;
@@ -2009,7 +2029,14 @@ static int emit_oa_config(struct i915_perf_stream
*stream,
i915_request_add(rq);
err_vma_unpin:
i915_vma_unpin(vma);
-err_vma_put:
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+
+ i915_gem_ww_ctx_fini();
i915_vma_put(vma);
return err;
}
--
2.25.0.24.g3f081b084b0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/20] drm/i915: Use ww locking in intel_renderstate.
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_gt.c | 21 +++---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 71 ++---
drivers/gpu/drm/i915/gt/intel_renderstate.h | 9 ++-
3 files changed, 65 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index d3e36a3b1d93..57dfa18da26a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -406,21 +406,20 @@ static int __engines_record_defaults(struct intel_gt *gt)
/* We must be able to switch to something! */
GEM_BUG_ON(!engine->kernel_context);
- err = intel_renderstate_init(, engine);
- if (err)
- goto out;
-
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
err = PTR_ERR(ce);
goto out;
}
- rq = intel_context_create_request(ce);
+ err = intel_renderstate_init(, ce);
+ if (err)
+ goto err;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- intel_context_put(ce);
- goto out;
+ goto err_fini;
}
err = intel_engine_emit_ctx_wa(rq);
@@ -434,9 +433,13 @@ static int __engines_record_defaults(struct intel_gt *gt)
err_rq:
requests[id] = i915_request_get(rq);
i915_request_add(rq);
- intel_renderstate_fini();
- if (err)
+err_fini:
+ intel_renderstate_fini(, ce);
+err:
+ if (err) {
+ intel_context_put(ce);
goto out;
+ }
}
/* Flush the default context image to memory, and enable powersaving. */
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c
b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index fff61e86cfbf..09ea4d0a14f9 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -27,6 +27,7 @@
#include "i915_drv.h"
#include "intel_renderstate.h"
+#include "gt/intel_context.h"
#include "intel_ring.h"
static const struct intel_renderstate_rodata *
@@ -74,10 +75,9 @@ static int render_state_setup(struct intel_renderstate *so,
u32 *d;
int ret;
- i915_gem_object_lock(so->vma->obj, NULL);
ret = i915_gem_object_prepare_write(so->vma->obj, _clflush);
if (ret)
- goto out_unlock;
+ return ret;
d = kmap_atomic(i915_gem_object_get_dirty_page(so->vma->obj, 0));
@@ -158,8 +158,6 @@ static int render_state_setup(struct intel_renderstate *so,
ret = 0;
out:
i915_gem_object_finish_access(so->vma->obj);
-out_unlock:
- i915_gem_object_unlock(so->vma->obj);
return ret;
err:
@@ -171,33 +169,47 @@ static int render_state_setup(struct intel_renderstate
*so,
#undef OUT_BATCH
int intel_renderstate_init(struct intel_renderstate *so,
- struct intel_engine_cs *engine)
+ struct intel_context *ce)
{
- struct drm_i915_gem_object *obj;
+ struct intel_engine_cs *engine = ce->engine;
+ struct drm_i915_gem_object *obj = NULL;
int err;
memset(so, 0, sizeof(*so));
so->rodata = render_state_get_rodata(engine);
- if (!so->rodata)
- return 0;
+ if (so->rodata) {
+ if (so->rodata->batch_items * 4 > PAGE_SIZE)
+ return -EINVAL;
+
+ obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ so->vma = i915_vma_instance(obj, >gt->ggtt->vm, NULL);
+ if (IS_ERR(so->vma)) {
+ err = PTR_ERR(so->vma);
+ goto err_obj;
+ }
+ }
- if (so->rodata->batch_items * 4 > PAGE_SIZE)
- return -EINVAL;
+ i915_gem_ww_ctx_init(>ww, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err_fini;
- obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ /* return early if there's nothing to setup */
+ if (!err && !so->rodata)
+ return 0;
- so->vma = i915_vma_instance(obj, >gt->ggtt->vm, NULL);
- if (IS_ERR(so->vma)) {
-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev3)
== Series Details ==
Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev3)
URL : https://patchwork.freedesktop.org/series/45968/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8004 -> Patchwork_16701
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16701:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_busy@basic@modeset}:
- fi-apl-guc: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-apl-guc/igt@kms_busy@ba...@modeset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-apl-guc/igt@kms_busy@ba...@modeset.html
- fi-icl-dsi: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-dsi/igt@kms_busy@ba...@modeset.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-icl-dsi/igt@kms_busy@ba...@modeset.html
- {fi-tgl-u}: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-u/igt@kms_busy@ba...@modeset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-tgl-u/igt@kms_busy@ba...@modeset.html
- {fi-tgl-dsi}: [PASS][7] -> [FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-tgl-dsi/igt@kms_busy@ba...@modeset.html
- fi-bxt-dsi: [PASS][9] -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-bxt-dsi/igt@kms_busy@ba...@modeset.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-bxt-dsi/igt@kms_busy@ba...@modeset.html
- fi-cfl-guc: [PASS][11] -> [FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cfl-guc/igt@kms_busy@ba...@modeset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-cfl-guc/igt@kms_busy@ba...@modeset.html
- fi-skl-6600u: NOTRUN -> [FAIL][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-skl-6600u/igt@kms_busy@ba...@modeset.html
- fi-cml-s: [PASS][14] -> [FAIL][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cml-s/igt@kms_busy@ba...@modeset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-cml-s/igt@kms_busy@ba...@modeset.html
- fi-skl-lmem:[PASS][16] -> [FAIL][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-skl-lmem/igt@kms_busy@ba...@modeset.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-skl-lmem/igt@kms_busy@ba...@modeset.html
- {fi-ehl-1}: NOTRUN -> [FAIL][18]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-ehl-1/igt@kms_busy@ba...@modeset.html
- fi-bsw-n3050: [PASS][19] -> [FAIL][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-bsw-n3050/igt@kms_busy@ba...@modeset.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-bsw-n3050/igt@kms_busy@ba...@modeset.html
- fi-icl-guc: [PASS][21] -> [FAIL][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-guc/igt@kms_busy@ba...@modeset.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-icl-guc/igt@kms_busy@ba...@modeset.html
- fi-byt-n2820: [PASS][23] -> [FAIL][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-byt-n2820/igt@kms_busy@ba...@modeset.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-byt-n2820/igt@kms_busy@ba...@modeset.html
- fi-skl-6700k2: [PASS][25] -> [FAIL][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-skl-6700k2/igt@kms_busy@ba...@modeset.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-skl-6700k2/igt@kms_busy@ba...@modeset.html
- fi-glk-dsi: [PASS][27] -> [FAIL][28]
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-glk-dsi/igt@kms_busy@ba...@modeset.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-glk-dsi/igt@kms_busy@ba...@modeset.html
- fi-bsw-kefka: [PASS][29] -> [FAIL][30]
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-bsw-kefka/igt@kms_busy@ba...@modeset.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-bsw-kefka/igt@kms_busy@ba...@modeset.html
- fi-skl-guc: [PASS][31] -> [FAIL][32]
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-skl-guc/igt@kms_busy@ba...@modeset.html
[32]:
[Intel-gfx] [PATCH 15/20] drm/i915: Kill last user of intel_context_create_request outside of selftests
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 887e0dc701f7..c3223e91258b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1659,6 +1659,7 @@ static int engine_wa_list_verify(struct intel_context *ce,
const struct i915_wa *wa;
struct i915_request *rq;
struct i915_vma *vma;
+ struct i915_gem_ww_ctx ww;
unsigned int i;
u32 *results;
int err;
@@ -1671,29 +1672,34 @@ static int engine_wa_list_verify(struct intel_context
*ce,
return PTR_ERR(vma);
intel_engine_pm_get(ce->engine);
- rq = intel_context_create_request(ce);
- intel_engine_pm_put(ce->engine);
+ i915_gem_ww_ctx_init(, false);
+retry:
+ err = i915_gem_object_lock(vma->obj, );
+ if (err == 0)
+ err = intel_context_pin_ww(ce, );
+ if (err)
+ goto err_pm;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto err_vma;
+ goto err_unpin;
}
- i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, true);
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
- if (err) {
- i915_request_add(rq);
- goto err_vma;
- }
-
- err = wa_list_srm(rq, wal, vma);
- if (err)
- goto err_vma;
+ if (err == 0)
+ err = wa_list_srm(rq, wal, vma);
i915_request_get(rq);
+ if (err)
+ i915_request_skip(rq, err);
i915_request_add(rq);
+
+ if (err)
+ goto err_rq;
+
if (i915_request_wait(rq, 0, HZ / 5) < 0) {
err = -ETIME;
goto err_rq;
@@ -1718,7 +1724,16 @@ static int engine_wa_list_verify(struct intel_context
*ce,
err_rq:
i915_request_put(rq);
-err_vma:
+err_unpin:
+ intel_context_unpin(ce);
+err_pm:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+ intel_engine_pm_put(ce->engine);
i915_vma_unpin(vma);
i915_vma_put(vma);
return err;
--
2.25.0.24.g3f081b084b0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/20] drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin.
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass ww at a point where we could still handle -EDEADLK safely.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 124 ++
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 4 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 4 +-
drivers/gpu/drm/i915/gt/intel_context.c | 65 +
drivers/gpu/drm/i915/gt/intel_context.h | 13 ++
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring.c | 10 +-
drivers/gpu/drm/i915/gt/intel_ring.h | 3 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 15 +--
drivers/gpu/drm/i915/gt/intel_timeline.c | 12 +-
drivers/gpu/drm/i915/gt/intel_timeline.h | 3 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 3 +-
drivers/gpu/drm/i915/gt/selftest_timeline.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 13 +-
drivers/gpu/drm/i915/i915_gem.c | 11 +-
drivers/gpu/drm/i915/i915_vma.c | 13 +-
drivers/gpu/drm/i915/i915_vma.h | 13 +-
24 files changed, 205 insertions(+), 127 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8af0272a5318..36cabc6c20b0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3441,7 +3441,7 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(vma))
goto err_obj;
- if (i915_ggtt_pin(vma, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
+ if (i915_ggtt_pin(vma, NULL, 0, PIN_MAPPABLE | PIN_OFFSET_FIXED | base))
goto err_obj;
if (i915_gem_object_is_tiled(obj) &&
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 914a6f0ee162..7823c0c1671d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1016,7 +1016,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
i915_gem_ww_ctx_init(, true);
retry:
- err = intel_context_pin(ce);
+ err = intel_context_pin_ww(ce, );
if (err)
goto err;
@@ -1109,7 +1109,7 @@ static int pin_ppgtt_update(struct intel_context *ce,
struct i915_gem_ww_ctx *ww
if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
/* ppGTT is not part of the legacy context image */
- return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+ return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm), ww);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 47bf9221a299..1bf319b78f13 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -396,7 +396,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
pin_flags |= PIN_GLOBAL;
- if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
+ if (unlikely(i915_vma_pin_ww(vma, >ww, 0, 0, pin_flags)))
return false;
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
@@ -543,7 +543,7 @@ static inline int use_cpu_reloc(const struct reloc_cache
*cache,
obj->cache_level != I915_CACHE_NONE);
}
-static int eb_reserve_vma(const struct i915_execbuffer *eb, struct eb_vma *ev)
+static int eb_reserve_vma(struct i915_execbuffer *eb, struct eb_vma *ev)
{
struct drm_i915_gem_exec_object2 *entry = ev->exec;
unsigned int exec_flags = ev->flags;
@@ -572,7 +572,7 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
struct eb_vma *ev)
pin_flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
}
- err = i915_vma_pin(vma,
+ err = i915_vma_pin_ww(vma, >ww,
entry->pad_to_size, entry->alignment,
pin_flags);
if (err)
@@ -1020,9 +1020,10 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
}
static void *reloc_iomap(struct drm_i915_gem_object *obj,
-struct reloc_cache *cache,
+struct i915_execbuffer
[Intel-gfx] [PATCH 04/20] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_ctx and obj order in locking functions (Jonas Lahtinen)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 10 ++--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 38 +++---
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../i915/gem/selftests/i915_gem_coherency.c | 10 ++--
.../drm/i915/gem/selftests/i915_gem_context.c | 4 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 4 +-
.../drm/i915/gem/selftests/i915_gem_phys.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 52 +--
drivers/gpu/drm/i915/i915_gem.h | 11
drivers/gpu/drm/i915/selftests/i915_gem.c | 41 +++
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
.../drm/i915/selftests/intel_memory_region.c | 2 +-
26 files changed, 175 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3031e64ee518..8af0272a5318 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2306,7 +2306,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
{
- i915_gem_object_lock(vma->obj);
+ i915_gem_object_lock(vma->obj, NULL);
if (flags & PLANE_HAS_FENCE)
i915_vma_unpin_fence(vma);
i915_gem_object_unpin_from_display_plane(vma);
@@ -17126,7 +17126,7 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
if (!intel_fb->frontbuffer)
return -ENOMEM;
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
tiling = i915_gem_object_get_tiling(obj);
stride = i915_gem_object_get_stride(obj);
i915_gem_object_unlock(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 81366aa4812b..d92a35163330 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -287,7 +287,7 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
dma_fence_init(>dma, _pages_work_ops, _lock, 0, 0);
i915_sw_fence_init(>wait, clear_pages_work_notify);
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
err = i915_sw_fence_await_reservation(>wait,
obj->base.resv, NULL,
true, I915_FENCE_TIMEOUT,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index adcebf22a3d3..af734ded602d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -114,7 +114,7 @@ static void lut_close(struct i915_gem_context *ctx)
continue;
rcu_read_unlock();
- i915_gem_object_lock(obj);
+ i915_gem_object_lock(obj, NULL);
list_for_each_entry(lut, >lut_list, obj_link) {
if (lut->ctx != ctx)
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 7db5a793739d..cfadccfc2990 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -128,7 +128,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
if (err)
return err;
- err = i915_gem_object_lock_interruptible(obj);
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
goto out;
@@ -149,7 +149,7 @@ static int i915_gem_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direct
if (err)
return err;
-
[Intel-gfx] [PATCH 20/20] drm/i915: Move i915_vma_lock in the live selftest to avoid lock inversion
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/selftests/i915_request.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..2a6052d609d9 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -848,6 +848,8 @@ static int live_all_engines(void *arg)
goto out_free;
}
+ i915_vma_lock(batch);
+
idx = 0;
for_each_uabi_engine(engine, i915) {
request[idx] = intel_engine_create_kernel_request(engine);
@@ -865,11 +867,9 @@ static int live_all_engines(void *arg)
GEM_BUG_ON(err);
request[idx]->batch = batch;
- i915_vma_lock(batch);
err = i915_request_await_object(request[idx], batch->obj, 0);
if (err == 0)
err = i915_vma_move_to_active(batch, request[idx], 0);
- i915_vma_unlock(batch);
GEM_BUG_ON(err);
i915_request_get(request[idx]);
@@ -877,6 +877,8 @@ static int live_all_engines(void *arg)
idx++;
}
+ i915_vma_unlock(batch);
+
idx = 0;
for_each_uabi_engine(engine, i915) {
if (i915_request_completed(request[idx])) {
--
2.25.0.24.g3f081b084b0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/20] drm/i915: Add ww context handling to context_barrier_task
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index af734ded602d..914a6f0ee162 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -975,12 +975,14 @@ I915_SELFTEST_DECLARE(static intel_engine_mask_t
context_barrier_inject_fault);
static int context_barrier_task(struct i915_gem_context *ctx,
intel_engine_mask_t engines,
bool (*skip)(struct intel_context *ce, void
*data),
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
int (*emit)(struct i915_request *rq, void
*data),
void (*task)(void *data),
void *data)
{
struct context_barrier_task *cb;
struct i915_gem_engines_iter it;
+ struct i915_gem_ww_ctx ww;
struct intel_context *ce;
int err = 0;
@@ -1012,10 +1014,21 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
if (skip && skip(ce, data))
continue;
- rq = intel_context_create_request(ce);
+ i915_gem_ww_ctx_init(, true);
+retry:
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ if (pin)
+ err = pin(ce, , data);
+ if (err)
+ goto err_unpin;
+
+ rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- break;
+ goto err_unpin;
}
err = 0;
@@ -1025,6 +1038,16 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
err = i915_active_add_request(>base, rq);
i915_request_add(rq);
+err_unpin:
+ intel_context_unpin(ce);
+err:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+
if (err)
break;
}
@@ -1080,6 +1103,17 @@ static void set_ppgtt_barrier(void *data)
i915_vm_close(old);
}
+static int pin_ppgtt_update(struct intel_context *ce, struct i915_gem_ww_ctx
*ww, void *data)
+{
+ struct i915_address_space *vm = ce->vm;
+
+ if (!HAS_LOGICAL_RING_CONTEXTS(vm->i915))
+ /* ppGTT is not part of the legacy context image */
+ return gen6_ppgtt_pin(i915_vm_to_ppgtt(vm));
+
+ return 0;
+}
+
static int emit_ppgtt_update(struct i915_request *rq, void *data)
{
struct i915_address_space *vm = rq->context->vm;
@@ -1136,20 +1170,10 @@ static int emit_ppgtt_update(struct i915_request *rq,
void *data)
static bool skip_ppgtt_update(struct intel_context *ce, void *data)
{
- if (!test_bit(CONTEXT_ALLOC_BIT, >flags))
- return true;
-
if (HAS_LOGICAL_RING_CONTEXTS(ce->engine->i915))
- return false;
-
- if (!atomic_read(>pin_count))
- return true;
-
- /* ppGTT is not part of the legacy context image */
- if (gen6_ppgtt_pin(i915_vm_to_ppgtt(ce->vm)))
- return true;
-
- return false;
+ return !ce->state;
+ else
+ return !atomic_read(>pin_count);
}
static int set_ppgtt(struct drm_i915_file_private *file_priv,
@@ -1200,6 +1224,7 @@ static int set_ppgtt(struct drm_i915_file_private
*file_priv,
*/
err = context_barrier_task(ctx, ALL_ENGINES,
skip_ppgtt_update,
+ pin_ppgtt_update,
emit_ppgtt_update,
set_ppgtt_barrier,
old);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index d3d8981b268f..50b465b62d88 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1904,8 +1904,8 @@ static int mock_context_barrier(void *arg)
return -ENOMEM;
counter = 0;
- err = context_barrier_task(ctx, 0,
- NULL, NULL, mock_barrier_task, );
+ err = context_barrier_task(ctx, 0, NULL, NULL, NULL,
+
[Intel-gfx] [PATCH 05/20] drm/i915: Remove locking from i915_gem_object_prepare_read/write
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 20 ++-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.h| 1 -
.../gpu/drm/i915/gem/selftests/huge_pages.c | 5 -
.../i915/gem/selftests/i915_gem_coherency.c | 14 +
.../drm/i915/gem/selftests/i915_gem_context.c | 12 ---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 5 -
drivers/gpu/drm/i915/gvt/cmd_parser.c | 9 -
drivers/gpu/drm/i915/i915_gem.c | 20 +--
9 files changed, 70 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index f4602faa8db9..e9d3b587f562 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -581,19 +581,17 @@ int i915_gem_object_prepare_read(struct
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
+ assert_object_held(obj);
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto err_unlock;
+ return ret;
ret = i915_gem_object_pin_pages(obj);
if (ret)
- goto err_unlock;
+ return ret;
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -621,8 +619,6 @@ int i915_gem_object_prepare_read(struct drm_i915_gem_object
*obj,
err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
- i915_gem_object_unlock(obj);
return ret;
}
@@ -635,20 +631,18 @@ int i915_gem_object_prepare_write(struct
drm_i915_gem_object *obj,
if (!i915_gem_object_has_struct_page(obj))
return -ENODEV;
- ret = i915_gem_object_lock_interruptible(obj, NULL);
- if (ret)
- return ret;
+ assert_object_held(obj);
ret = i915_gem_object_wait(obj,
I915_WAIT_INTERRUPTIBLE |
I915_WAIT_ALL,
MAX_SCHEDULE_TIMEOUT);
if (ret)
- goto err_unlock;
+ return ret;
ret = i915_gem_object_pin_pages(obj);
if (ret)
- goto err_unlock;
+ return ret;
if (obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE ||
!static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -685,7 +679,5 @@ int i915_gem_object_prepare_write(struct
drm_i915_gem_object *obj,
err_unpin:
i915_gem_object_unpin_pages(obj);
-err_unlock:
- i915_gem_object_unlock(obj);
return ret;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f567e4c99e29..e7dd29541727 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -933,11 +933,14 @@ static void reloc_cache_reset(struct reloc_cache *cache)
vaddr = unmask_page(cache->vaddr);
if (cache->vaddr & KMAP) {
+ struct drm_i915_gem_object *obj =
+ (struct drm_i915_gem_object *)cache->node.mm;
if (cache->vaddr & CLFLUSH_AFTER)
mb();
kunmap_atomic(vaddr);
- i915_gem_object_finish_access((struct drm_i915_gem_object
*)cache->node.mm);
+ i915_gem_object_finish_access(obj);
+ i915_gem_object_unlock(obj);
} else {
struct i915_ggtt *ggtt = cache_to_ggtt(cache);
@@ -972,10 +975,16 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
unsigned int flushes;
int err;
- err = i915_gem_object_prepare_write(obj, );
+ err = i915_gem_object_lock_interruptible(obj, NULL);
if (err)
return ERR_PTR(err);
+ err = i915_gem_object_prepare_write(obj, );
+ if (err) {
+ i915_gem_object_unlock(obj);
+ return ERR_PTR(err);
+ }
+
BUILD_BUG_ON(KMAP & CLFLUSH_FLAGS);
BUILD_BUG_ON((KMAP | CLFLUSH_FLAGS) & PAGE_MASK);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 95e732f83d06..9f381490b7c6 100644
---
[Intel-gfx] [PATCH 07/20] drm/i915: Use per object locking in execbuf on top of struct_mutex, v4.
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This finally allows us to do parallel submission, but because vma
pinning does not use the ww ctx yet, we cannot drop struct_mutex yet.
Changes since v1:
- Keep struct_mutex for now. :(
Changes since v2:
- Make sure we always lock the ww context in slowpath.
Changes since v3:
- Don't call __eb_unreserve_vma in eb_move_to_gpu now; this can be
done on normal unlock path.
- Unconditionally release vmas and context.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 169 --
1 file changed, 78 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bcbcd0ea8da6..8f39ffc277e7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -251,6 +251,8 @@ struct i915_execbuffer {
/** list of vma that have execobj.relocation_count */
struct list_head relocs;
+ struct i915_gem_ww_ctx ww;
+
/**
* Track the most recently used object for relocations, as we
* frequently have to perform multiple relocations within the same
@@ -406,24 +408,18 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
}
-static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
-{
- GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
-
- if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
- __i915_vma_unpin_fence(vma);
-
- __i915_vma_unpin(vma);
-}
-
static inline void
eb_unreserve_vma(struct eb_vma *ev)
{
if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
return;
- __eb_unreserve_vma(ev->vma, ev->flags);
ev->flags &= ~__EXEC_OBJECT_RESERVED;
+
+ if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
+ __i915_vma_unpin_fence(ev->vma);
+
+ __i915_vma_unpin(ev->vma);
}
static int
@@ -813,6 +809,10 @@ static int eb_validate_vmas(struct i915_execbuffer *eb)
struct eb_vma *ev = >vma[i];
struct i915_vma *vma = ev->vma;
+ err = i915_gem_object_lock(vma->obj, >ww);
+ if (err)
+ return err;
+
if (eb_pin_vma(eb, entry, ev)) {
if (entry->offset != vma->node.start) {
entry->offset = vma->node.start | UPDATE;
@@ -959,7 +959,6 @@ static void reloc_cache_reset(struct reloc_cache *cache)
kunmap_atomic(vaddr);
i915_gem_object_finish_access(obj);
- i915_gem_object_unlock(obj);
} else {
struct i915_ggtt *ggtt = cache_to_ggtt(cache);
@@ -994,15 +993,9 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
unsigned int flushes;
int err;
- err = i915_gem_object_lock_interruptible(obj, NULL);
- if (err)
- return ERR_PTR(err);
-
err = i915_gem_object_prepare_write(obj, );
- if (err) {
- i915_gem_object_unlock(obj);
+ if (err)
return ERR_PTR(err);
- }
BUILD_BUG_ON(KMAP & CLFLUSH_FLAGS);
BUILD_BUG_ON((KMAP | CLFLUSH_FLAGS) & PAGE_MASK);
@@ -1041,9 +1034,7 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
if (use_cpu_reloc(cache, obj))
return NULL;
- i915_gem_object_lock(obj, NULL);
err = i915_gem_object_set_to_gtt_domain(obj, true);
- i915_gem_object_unlock(obj);
if (err)
return ERR_PTR(err);
@@ -1132,7 +1123,7 @@ static int reloc_move_to_gpu(struct i915_request *rq,
struct i915_vma *vma)
struct drm_i915_gem_object *obj = vma->obj;
int err;
- i915_vma_lock(vma);
+ assert_vma_held(vma);
if (obj->cache_dirty & ~obj->cache_coherent)
i915_gem_clflush_object(obj, 0);
@@ -1142,8 +1133,6 @@ static int reloc_move_to_gpu(struct i915_request *rq,
struct i915_vma *vma)
if (err == 0)
err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(vma);
-
return err;
}
@@ -1162,6 +1151,10 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
if (IS_ERR(pool))
return PTR_ERR(pool);
+ err = i915_gem_object_lock(pool->obj, >ww);
+ if (err)
+ goto out_pool;
+
cmd = i915_gem_object_pin_map(pool->obj,
[Intel-gfx] [PATCH 10/20] drm/i915: Nuke arguments to eb_pin_engine
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 8f39ffc277e7..325b6d173021 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2379,11 +2379,10 @@ static void eb_unpin_engine(struct i915_execbuffer *eb)
}
static unsigned int
-eb_select_legacy_ring(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_select_legacy_ring(struct i915_execbuffer *eb)
{
struct drm_i915_private *i915 = eb->i915;
+ struct drm_i915_gem_execbuffer2 *args = eb->args;
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
if (user_ring_id != I915_EXEC_BSD &&
@@ -2398,7 +2397,7 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
- bsd_idx = gen8_dispatch_bsd_engine(i915, file);
+ bsd_idx = gen8_dispatch_bsd_engine(i915, eb->file);
} else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
bsd_idx <= I915_EXEC_BSD_RING2) {
bsd_idx >>= I915_EXEC_BSD_SHIFT;
@@ -2423,18 +2422,16 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
}
static int
-eb_pin_engine(struct i915_execbuffer *eb,
- struct drm_file *file,
- struct drm_i915_gem_execbuffer2 *args)
+eb_pin_engine(struct i915_execbuffer *eb)
{
struct intel_context *ce;
unsigned int idx;
int err;
if (i915_gem_context_user_engines(eb->gem_context))
- idx = args->flags & I915_EXEC_RING_MASK;
+ idx = eb->args->flags & I915_EXEC_RING_MASK;
else
- idx = eb_select_legacy_ring(eb, file, args);
+ idx = eb_select_legacy_ring(eb);
ce = i915_gem_context_get_engine(eb->gem_context, idx);
if (IS_ERR(ce))
@@ -2667,7 +2664,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (unlikely(err))
goto err_destroy;
- err = eb_pin_engine(, file, args);
+ err = eb_pin_engine();
if (unlikely(err))
goto err_context;
--
2.25.0.24.g3f081b084b0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/20] drm/i915: Parse command buffer earlier in eb_relocate(slow)
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get called from execbuf
relocation fast and slowpath.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 66 +++
1 file changed, 37 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index e7dd29541727..bcbcd0ea8da6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -287,6 +287,8 @@ struct i915_execbuffer {
struct hlist_head *buckets; /** ht for relocation handles */
};
+static int eb_parse(struct i915_execbuffer *eb);
+
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -706,6 +708,7 @@ static int eb_select_context(struct i915_execbuffer *eb)
static int eb_lookup_vmas(struct i915_execbuffer *eb)
{
struct radix_tree_root *handles_vma = >gem_context->handles_vma;
+ struct drm_i915_private *i915 = eb->i915;
struct drm_i915_gem_object *obj;
unsigned int i, batch;
int err;
@@ -771,6 +774,22 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
mutex_unlock(>gem_context->mutex);
+ if (unlikely(eb->batch->flags & EXEC_OBJECT_WRITE)) {
+ drm_dbg(>drm,
+ "Attempting to use self-modifying batch buffer\n");
+ return -EINVAL;
+ }
+
+ if (range_overflows_t(u64,
+ eb->batch_start_offset, eb->batch_len,
+ eb->batch->vma->size)) {
+ drm_dbg(>drm, "Attempting to use out-of-bounds batch\n");
+ return -EINVAL;
+ }
+
+ if (eb->batch_len == 0)
+ eb->batch_len = eb->batch->vma->size - eb->batch_start_offset;
+
return 0;
err_obj:
@@ -1661,7 +1680,7 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
{
struct drm_device *dev = >i915->drm;
bool have_copy = false;
@@ -1735,6 +1754,11 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
}
}
+ /* as last step, parse the command buffer */
+ err = eb_parse(eb);
+ if (err)
+ goto err;
+
/*
* Leave the user relocations as are, this is the painfully slow path,
* and we want to avoid the complication of dropping the lock whilst
@@ -1767,7 +1791,7 @@ static noinline int eb_relocate_slow(struct
i915_execbuffer *eb)
return err;
}
-static int eb_relocate(struct i915_execbuffer *eb)
+static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
@@ -1775,7 +1799,8 @@ static int eb_relocate(struct i915_execbuffer *eb)
if (err)
return err;
- if (eb_validate_vmas(eb))
+ err = eb_validate_vmas(eb);
+ if (err)
goto slow;
/* The objects are in their final locations, apply the relocations. */
@@ -1788,10 +1813,14 @@ static int eb_relocate(struct i915_execbuffer *eb)
}
}
+ err = eb_parse(eb);
+ if (err)
+ goto slow;
+
return 0;
slow:
- return eb_relocate_slow(eb);
+ return eb_relocate_parse_slow(eb);
}
static int eb_move_to_gpu(struct i915_execbuffer *eb)
@@ -2663,7 +2692,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (err)
goto err_engine;
- err = eb_relocate();
+ err = eb_relocate_parse();
if (err) {
/*
* If the user expects the execobject.offset and
@@ -2676,33 +2705,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_vma;
}
- if (unlikely(eb.batch->flags & EXEC_OBJECT_WRITE)) {
- drm_dbg(>drm,
- "Attempting to use self-modifying batch buffer\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (range_overflows_t(u64,
- eb.batch_start_offset, eb.batch_len,
- eb.batch->vma->size)) {
- drm_dbg(>drm, "Attempting to use out-of-bounds batch\n");
- err = -EINVAL;
- goto err_vma;
- }
-
- if (eb.batch_len == 0)
- eb.batch_len = eb.batch->vma->size - eb.batch_start_offset;
-
- err = eb_parse();
- if (err)
- goto err_vma;
-
/*
* snb/ivb/vlv conflate
[Intel-gfx] [PATCH 11/20] drm/i915: Pin engine before pinning all objects, v3.
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take the fastpath, if not we will take the slowpath and wait for
the throttle request while unlocked.
The engine has to be pinned as first step, otherwise gpu relocations
won't work.
Changes since v1:
- Only need to get a throttled request in the fastpath, no need for
a global flag any more.
- Always free the waited request correctly.
Changes since v2:
- Use intel_engine_pm_get()/put() to keeep engine pool alive during
EDEADLK handling.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 159 --
1 file changed, 108 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 325b6d173021..47bf9221a299 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -17,6 +17,7 @@
#include "gem/i915_gem_ioctls.h"
#include "gt/intel_context.h"
#include "gt/intel_engine_pool.h"
+#include "gt/intel_engine_pm.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
#include "gt/intel_ring.h"
@@ -57,7 +58,8 @@ enum {
#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
-#define __EXEC_INTERNAL_FLAGS (~0u << 31)
+#define __EXEC_ENGINE_PINNED BIT(30)
+#define __EXEC_INTERNAL_FLAGS (~0u << 30)
#define UPDATE PIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -290,6 +292,9 @@ struct i915_execbuffer {
};
static int eb_parse(struct i915_execbuffer *eb);
+static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
+ bool throttle);
+static void eb_unpin_engine(struct i915_execbuffer *eb);
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
@@ -856,7 +861,7 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned long
handle)
}
}
-static void eb_release_vmas(const struct i915_execbuffer *eb)
+static void eb_release_vmas(struct i915_execbuffer *eb)
{
const unsigned int count = eb->buffer_count;
unsigned int i;
@@ -872,8 +877,9 @@ static void eb_release_vmas(const struct i915_execbuffer
*eb)
if (ev->flags & __EXEC_OBJECT_HAS_REF)
i915_vma_put(vma);
-
}
+
+ eb_unpin_engine(eb);
}
static void eb_destroy(const struct i915_execbuffer *eb)
@@ -1674,7 +1680,8 @@ static int eb_prefault_relocations(const struct
i915_execbuffer *eb)
return 0;
}
-static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb)
+static noinline int eb_relocate_parse_slow(struct i915_execbuffer *eb,
+ struct i915_request *rq)
{
struct drm_device *dev = >i915->drm;
bool have_copy = false;
@@ -1692,6 +1699,20 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
i915_gem_ww_ctx_fini(>ww);
mutex_unlock(>struct_mutex);
+ if (rq) {
+ if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
+ MAX_SCHEDULE_TIMEOUT) < 0) {
+ i915_request_put(rq);
+ rq = NULL;
+
+ err = -EINTR;
+ goto err_relock;
+ }
+
+ i915_request_put(rq);
+ rq = NULL;
+ }
+
/*
* We take 3 passes through the slowpatch.
*
@@ -1721,6 +1742,8 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
err = mutex_lock_interruptible(>struct_mutex);
}
+
+err_relock:
if (err) {
mutex_lock(>struct_mutex);
i915_gem_ww_ctx_init(>ww, true);
@@ -1730,6 +1753,15 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
/* reacquire the objects */
repeat_validate:
+ rq = eb_pin_engine(eb, false);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err;
+ }
+
+ /* We didn't throttle, should be NULL */
+ GEM_WARN_ON(rq);
+
err = eb_validate_vmas(eb);
if (err)
goto err;
@@ -1793,18 +1825,41 @@ static noinline int eb_relocate_parse_slow(struct
i915_execbuffer *eb)
}
}
+ if (rq)
+ i915_request_put(rq);
+
return err;
}
static int eb_relocate_parse(struct i915_execbuffer *eb)
{
int err;
+ struct i915_request *rq = NULL;
+ bool throttle = true;
err = eb_lookup_vmas(eb);
if (err)
return err;
retry:
+ rq = eb_pin_engine(eb,
[Intel-gfx] [PATCH 18/20] drm/i915/selftests: Fix locking inversion in lrc selftest.
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index febd608c23a7..d312b847172b 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -4226,6 +4226,7 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
{
struct intel_context *ce;
struct i915_request *rq;
+ struct i915_gem_ww_ctx ww;
enum {
RING_START_IDX = 0,
RING_TAIL_IDX,
@@ -4240,7 +4241,11 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
if (IS_ERR(ce))
return PTR_ERR(ce);
- err = intel_context_pin(ce);
+ i915_gem_ww_ctx_init(, false);
+retry:
+ err = i915_gem_object_lock(scratch->obj, );
+ if (!err)
+ err = intel_context_pin_ww(ce, );
if (err)
goto err_put;
@@ -4269,11 +4274,9 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
*cs++ = i915_ggtt_offset(scratch) + RING_TAIL_IDX * sizeof(u32);
*cs++ = 0;
- i915_vma_lock(scratch);
err = i915_request_await_object(rq, scratch->obj, true);
if (!err)
err = i915_vma_move_to_active(scratch, rq, EXEC_OBJECT_WRITE);
- i915_vma_unlock(scratch);
i915_request_get(rq);
i915_request_add(rq);
@@ -4310,6 +4313,12 @@ static int __live_lrc_state(struct intel_engine_cs
*engine,
err_unpin:
intel_context_unpin(ce);
err_put:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
intel_context_put(ce);
return err;
}
--
2.25.0.24.g3f081b084b0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/20] drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2.
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/put() calls to fix use-after-free when using
intel_engine_get_pool().
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 80 +++--
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 156 +++---
.../gpu/drm/i915/gem/i915_gem_object_blt.h| 3 +
3 files changed, 165 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index d92a35163330..e9b45f6b1479 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -157,6 +157,7 @@ static void clear_pages_worker(struct work_struct *work)
struct clear_pages_work *w = container_of(work, typeof(*w), work);
struct drm_i915_gem_object *obj = w->sleeve->vma->obj;
struct i915_vma *vma = w->sleeve->vma;
+ struct i915_gem_ww_ctx ww;
struct i915_request *rq;
struct i915_vma *batch;
int err = w->dma.error;
@@ -172,17 +173,20 @@ static void clear_pages_worker(struct work_struct *work)
obj->read_domains = I915_GEM_GPU_DOMAINS;
obj->write_domain = 0;
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
- if (unlikely(err))
+ i915_gem_ww_ctx_init(, false);
+ intel_engine_pm_get(w->ce->engine);
+retry:
+ err = intel_context_pin_ww(w->ce, );
+ if (err)
goto out_signal;
- batch = intel_emit_vma_fill_blt(w->ce, vma, w->value);
+ batch = intel_emit_vma_fill_blt(w->ce, vma, , w->value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
- goto out_unpin;
+ goto out_ctx;
}
- rq = intel_context_create_request(w->ce);
+ rq = i915_request_create(w->ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto out_batch;
@@ -224,9 +228,19 @@ static void clear_pages_worker(struct work_struct *work)
i915_request_add(rq);
out_batch:
intel_emit_vma_release(w->ce, batch);
-out_unpin:
- i915_vma_unpin(vma);
+out_ctx:
+ intel_context_unpin(w->ce);
out_signal:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+
+ i915_vma_unpin(w->sleeve->vma);
+ intel_engine_pm_put(w->ce->engine);
+
if (unlikely(err)) {
dma_fence_set_error(>dma, err);
dma_fence_signal(>dma);
@@ -234,6 +248,45 @@ static void clear_pages_worker(struct work_struct *work)
}
}
+static int pin_wait_clear_pages_work(struct clear_pages_work *w,
+struct intel_context *ce)
+{
+ struct i915_vma *vma = w->sleeve->vma;
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ i915_gem_ww_ctx_init(, false);
+retry:
+ err = i915_gem_object_lock(vma->obj, );
+ if (err)
+ goto out;
+
+ err = i915_vma_pin_ww(vma, , 0, 0, PIN_USER);
+ if (unlikely(err))
+ goto out;
+
+ err = i915_sw_fence_await_reservation(>wait,
+ vma->obj->base.resv, NULL,
+ true, I915_FENCE_TIMEOUT,
+ I915_FENCE_GFP);
+ if (err)
+ goto err_unpin_vma;
+
+ dma_resv_add_excl_fence(vma->obj->base.resv, >dma);
+
+err_unpin_vma:
+ if (err)
+ i915_vma_unpin(vma);
+out:
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff();
+ if (!err)
+ goto retry;
+ }
+ i915_gem_ww_ctx_fini();
+ return err;
+}
+
static int __i915_sw_fence_call
clear_pages_work_notify(struct i915_sw_fence *fence,
enum i915_sw_fence_notify state)
@@ -287,18 +340,9 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
dma_fence_init(>dma, _pages_work_ops, _lock, 0, 0);
i915_sw_fence_init(>wait, clear_pages_work_notify);
- i915_gem_object_lock(obj, NULL);
- err = i915_sw_fence_await_reservation(>wait,
- obj->base.resv, NULL,
- true, I915_FENCE_TIMEOUT,
- I915_FENCE_GFP);
- if (err < 0) {
+ err = pin_wait_clear_pages_work(work, ce);
+ if (err < 0)
dma_fence_set_error(>dma, err);
- } else {
- dma_resv_add_excl_fence(obj->base.resv, >dma);
- err = 0;
- }
-
[Intel-gfx] [PATCH 17/20] drm/i915: Dirty hack to fix selftests locking inversion
Some i915 selftests still use i915_vma_lock() as inner lock, and intel_context_create_request() intel_timeline->mutex as outer lock. Fortunately for selftests this is not an issue, they should be fixed but we can move ahead and cleanify lockdep now. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index bc9a451ea9f3..c5dc714958f2 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -450,6 +450,18 @@ struct i915_request *intel_context_create_request(struct intel_context *ce) rq = i915_request_create(ce); intel_context_unpin(ce); + if (IS_ERR(rq)) + return rq; + + /* +* timeline->mutex should be the inner lock, but is used as outer lock. +* Hack around this to shut up lockdep in selftests.. +*/ + lockdep_unpin_lock(>timeline->mutex, rq->cookie); + mutex_release(>timeline->mutex.dep_map, _RET_IP_); + mutex_acquire(>timeline->mutex.dep_map, SINGLE_DEPTH_NESTING, 0, _RET_IP_); + rq->cookie = lockdep_pin_lock(>timeline->mutex); + return rq; } -- 2.25.0.24.g3f081b084b0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/20] drm/i915: Rework intel_context pinning to do everything outside of pin_mutex
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us to take pin refcounts correctly
all the time.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 223 +++---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 ++-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 1 -
.../gpu/drm/i915/gt/intel_ring_submission.c | 13 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 13 +-
6 files changed, 186 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 8bb444cda14f..ff5ee268ca58 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -88,74 +88,6 @@ static void intel_context_active_release(struct
intel_context *ce)
i915_active_release(>active);
}
-int __intel_context_do_pin(struct intel_context *ce)
-{
- int err;
-
- if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, >flags))) {
- err = intel_context_alloc_state(ce);
- if (err)
- return err;
- }
-
- err = i915_active_acquire(>active);
- if (err)
- return err;
-
- if (mutex_lock_interruptible(>pin_mutex)) {
- err = -EINTR;
- goto out_release;
- }
-
- if (likely(!atomic_add_unless(>pin_count, 1, 0))) {
- err = intel_context_active_acquire(ce);
- if (unlikely(err))
- goto out_unlock;
-
- err = ce->ops->pin(ce);
- if (unlikely(err))
- goto err_active;
-
- CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
-i915_ggtt_offset(ce->ring->vma),
-ce->ring->head, ce->ring->tail);
-
- smp_mb__before_atomic(); /* flush pin before it is visible */
- atomic_inc(>pin_count);
- }
-
- GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
- GEM_BUG_ON(i915_active_is_idle(>active));
- goto out_unlock;
-
-err_active:
- intel_context_active_release(ce);
-out_unlock:
- mutex_unlock(>pin_mutex);
-out_release:
- i915_active_release(>active);
- return err;
-}
-
-void intel_context_unpin(struct intel_context *ce)
-{
- if (!atomic_dec_and_test(>pin_count))
- return;
-
- CE_TRACE(ce, "unpin\n");
- ce->ops->unpin(ce);
-
- /*
-* Once released, we may asynchronously drop the active reference.
-* As that may be the only reference keeping the context alive,
-* take an extra now so that it is not freed before we finish
-* dereferencing it.
-*/
- intel_context_get(ce);
- intel_context_active_release(ce);
- intel_context_put(ce);
-}
-
static int __context_pin_state(struct i915_vma *vma)
{
unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
@@ -215,6 +147,133 @@ static void __ring_retire(struct intel_ring *ring)
i915_active_release(>vma->active);
}
+static int intel_context_pre_pin(struct intel_context *ce)
+{
+ int err;
+
+ CE_TRACE(ce, "active\n");
+
+ err = __ring_active(ce->ring);
+ if (err)
+ return err;
+
+ err = intel_timeline_pin(ce->timeline);
+ if (err)
+ goto err_ring;
+
+ if (!ce->state)
+ return 0;
+
+ err = __context_pin_state(ce->state);
+ if (err)
+ goto err_timeline;
+
+
+ return 0;
+
+err_timeline:
+ intel_timeline_unpin(ce->timeline);
+err_ring:
+ __ring_retire(ce->ring);
+ return err;
+}
+
+static void intel_context_post_unpin(struct intel_context *ce)
+{
+ if (ce->state)
+ __context_unpin_state(ce->state);
+
+ intel_timeline_unpin(ce->timeline);
+ __ring_retire(ce->ring);
+}
+
+int __intel_context_do_pin(struct intel_context *ce)
+{
+ bool handoff = false;
+ void *vaddr;
+ int err = 0;
+
+ if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, >flags))) {
+ err = intel_context_alloc_state(ce);
+ if (err)
+ return err;
+ }
+
+ /*
+* We always pin the context/ring/timeline here, to ensure a pin
+* refcount for __intel_context_active(), which prevent a lock
+* inversion of ce->pin_mutex vs dma_resv_lock().
+*/
+ err = intel_context_pre_pin(ce);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(>active);
+ if (err)
+ goto err_ctx_unpin;
+
+ err =
[Intel-gfx] [PATCH 03/20] drm/i915: Separate lookup and pinning in execbuf.
We want to get rid of struct mutex, but vma reservation was entangled
with vma lookup. Make vma lookup and validation a preparation step,
and vma pinning a repeatable step. This allows us to keep all the looked
up information when dropping all locks, which saves an extra lookup during
relocation slowpath.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 98 ++-
drivers/gpu/drm/i915/i915_drv.h | 6 --
2 files changed, 54 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index efec64e92a74..9970f5111daa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -57,8 +57,7 @@ enum {
#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
-#define __EXEC_VALIDATED BIT(30)
-#define __EXEC_INTERNAL_FLAGS (~0u << 30)
+#define __EXEC_INTERNAL_FLAGS (~0u << 31)
#define UPDATE PIN_OFFSET_FIXED
#define BATCH_OFFSET_BIAS (256*1024)
@@ -484,11 +483,9 @@ eb_add_vma(struct i915_execbuffer *eb,
GEM_BUG_ON(i915_vma_is_closed(vma));
- if (!(eb->args->flags & __EXEC_VALIDATED)) {
- err = eb_validate_vma(eb, entry, vma);
- if (unlikely(err))
- return err;
- }
+ err = eb_validate_vma(eb, entry, vma);
+ if (unlikely(err))
+ return err;
ev->vma = vma;
ev->exec = entry;
@@ -523,20 +520,7 @@ eb_add_vma(struct i915_execbuffer *eb,
eb->batch = ev;
}
- err = 0;
- if (eb_pin_vma(eb, entry, ev)) {
- if (entry->offset != vma->node.start) {
- entry->offset = vma->node.start | UPDATE;
- eb->args->flags |= __EXEC_HAS_RELOC;
- }
- } else {
- eb_unreserve_vma(ev);
-
- list_add_tail(>bind_link, >unbound);
- if (drm_mm_node_allocated(>node))
- err = i915_vma_unbind(vma);
- }
- return err;
+ return 0;
}
static inline int use_cpu_reloc(const struct reloc_cache *cache,
@@ -727,7 +711,6 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
int err;
INIT_LIST_HEAD(>relocs);
- INIT_LIST_HEAD(>unbound);
batch = eb_batch_index(eb);
@@ -784,15 +767,11 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
err = eb_add_vma(eb, i, batch, vma);
if (unlikely(err))
goto err_vma;
-
- GEM_BUG_ON(drm_mm_node_allocated(>node) &&
- eb_vma_misplaced(>exec[i], vma,
eb->vma[i].flags));
}
mutex_unlock(>gem_context->mutex);
- eb->args->flags |= __EXEC_VALIDATED;
- return eb_reserve(eb);
+ return 0;
err_obj:
i915_gem_object_put(obj);
@@ -803,6 +782,41 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
return err;
}
+static int eb_validate_vmas(struct i915_execbuffer *eb)
+{
+ unsigned int i;
+ int err;
+
+ INIT_LIST_HEAD(>unbound);
+
+ for (i = 0; i < eb->buffer_count; i++) {
+ struct drm_i915_gem_exec_object2 *entry = >exec[i];
+ struct eb_vma *ev = >vma[i];
+ struct i915_vma *vma = ev->vma;
+
+ if (eb_pin_vma(eb, entry, ev)) {
+ if (entry->offset != vma->node.start) {
+ entry->offset = vma->node.start | UPDATE;
+ eb->args->flags |= __EXEC_HAS_RELOC;
+ }
+ } else {
+ eb_unreserve_vma(ev);
+
+ list_add_tail(>bind_link, >unbound);
+ if (drm_mm_node_allocated(>node)) {
+ err = i915_vma_unbind(vma);
+ if (err)
+ return err;
+ }
+ }
+
+ GEM_BUG_ON(drm_mm_node_allocated(>node) &&
+ eb_vma_misplaced(>exec[i], vma, ev->flags));
+ }
+
+ return eb_reserve(eb);
+}
+
static struct eb_vma *
eb_get_vma(const struct i915_execbuffer *eb, unsigned long handle)
{
@@ -835,22 +849,12 @@ static void eb_release_vmas(const struct i915_execbuffer
*eb)
if (!vma)
break;
- eb->vma[i].vma = NULL;
-
- if (ev->flags & __EXEC_OBJECT_HAS_PIN)
- __eb_unreserve_vma(vma, ev->flags);
+ eb_unreserve_vma(ev);
if (ev->flags & __EXEC_OBJECT_HAS_REF)
i915_vma_put(vma);
- }
-}
-static void eb_reset_vmas(const struct i915_execbuffer *eb)
-{
- eb_release_vmas(eb);
- if
[Intel-gfx] [PATCH 01/20] drm/i915: Drop inspection of execbuf flags during evict
From: Chris Wilson
With the goal of removing the serialisation from around execbuf, we will
no longer have the privilege of there being a single execbuf in flight
at any time and so will only be able to inspect the user's flags within
the carefully controlled execbuf context. i915_gem_evict_for_node() is
the only user outside of execbuf that currently peeks at the flag to
convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
this nicety and only report ENOSPC if the location is in current use,
either due to this execbuf or another.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203121316.2972257-1-ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_evict.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 0697bedebeef..b75fd3ccd63b 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -292,7 +292,8 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
GEM_BUG_ON(!drm_mm_node_allocated(node));
vma = container_of(node, typeof(*vma), node);
- /* If we are using coloring to insert guard pages between
+ /*
+* If we are using coloring to insert guard pages between
* different cache domains within the address space, we have
* to check whether the objects on either side of our range
* abutt and conflict. If they are in conflict, then we evict
@@ -309,22 +310,18 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
}
}
- if (flags & PIN_NONBLOCK &&
- (i915_vma_is_pinned(vma) || i915_vma_is_active(vma))) {
+ if (i915_vma_is_pinned(vma)) {
ret = -ENOSPC;
break;
}
- /* Overlap of objects in the same batch? */
- if (i915_vma_is_pinned(vma)) {
+ if (flags & PIN_NONBLOCK && i915_vma_is_active(vma)) {
ret = -ENOSPC;
- if (vma->exec_flags &&
- *vma->exec_flags & EXEC_OBJECT_PINNED)
- ret = -EINVAL;
break;
}
- /* Never show fear in the face of dragons!
+ /*
+* Never show fear in the face of dragons!
*
* We cannot directly remove this node from within this
* iterator and as with i915_gem_evict_something() we employ
--
2.25.0.24.g3f081b084b0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/20] drm/i915/gem: Extract transient execbuf flags from i915_vma
From: Chris Wilson
For our convenience, and to avoid frequent allocations, we placed some
lists we use for execbuf inside the common i915_vma struct. As we look
to parallelise execbuf, such fields guarded by the struct_mutex BKL must
be pulled under local control. Instead of using the i915_vma as our
primary means of tracking the user's list of objects and their virtual
mappings, we use a local eb_vma with the same lists as before (just now
local not global).
This should allow us to only perform the lookup of vma used for
execution once during the execbuf ioctl, as currently we need to remove
our secrets from inside i915_vma everytime we drop the struct_mutex as
another execbuf may use the shared locations.
Once user visible consequence is that we can remove the requirement that
the execobj[] be unique, and only require that they do not conflict
(i.e. you cannot softpin the same object into two locations... hmm, we
could allow that if truly required, but atm we only allow one vma per
ppGTT per object.)
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203121316.2972257-2-ch...@chris-wilson.co.uk
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 279 +-
drivers/gpu/drm/i915/i915_vma_types.h | 11 -
2 files changed, 132 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 87fa5f42c39a..efec64e92a74 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -28,6 +28,19 @@
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
+struct eb_vma {
+ struct i915_vma *vma;
+ unsigned int flags;
+
+ /** This vma's place in the execbuf reservation list */
+ struct drm_i915_gem_exec_object2 *exec;
+ struct list_head bind_link;
+ struct list_head reloc_link;
+
+ struct hlist_node node;
+ u32 handle;
+};
+
enum {
FORCE_CPU_RELOC = 1,
FORCE_GTT_RELOC,
@@ -220,15 +233,14 @@ struct i915_execbuffer {
struct drm_file *file; /** per-file lookup tables and limits */
struct drm_i915_gem_execbuffer2 *args; /** ioctl parameters */
struct drm_i915_gem_exec_object2 *exec; /** ioctl execobj[] */
- struct i915_vma **vma;
- unsigned int *flags;
+ struct eb_vma *vma;
struct intel_engine_cs *engine; /** engine to queue the request to */
struct intel_context *context; /* logical state for the request */
struct i915_gem_context *gem_context; /** caller's context */
struct i915_request *request; /** our request to build */
- struct i915_vma *batch; /** identity of the batch obj/vma */
+ struct eb_vma *batch; /** identity of the batch obj/vma */
struct i915_vma *trampoline; /** trampoline used for chaining */
/** actual size of execobj[] as we may extend it for the cmdparser */
@@ -276,8 +288,6 @@ struct i915_execbuffer {
struct hlist_head *buckets; /** ht for relocation handles */
};
-#define exec_entry(EB, VMA) (&(EB)->exec[(VMA)->exec_flags - (EB)->flags])
-
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_requires_cmd_parser(eb->engine) ||
@@ -364,9 +374,9 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
static inline bool
eb_pin_vma(struct i915_execbuffer *eb,
const struct drm_i915_gem_exec_object2 *entry,
- struct i915_vma *vma)
+ struct eb_vma *ev)
{
- unsigned int exec_flags = *vma->exec_flags;
+ struct i915_vma *vma = ev->vma;
u64 pin_flags;
if (vma->node.size)
@@ -375,24 +385,24 @@ eb_pin_vma(struct i915_execbuffer *eb,
pin_flags = entry->offset & PIN_OFFSET_MASK;
pin_flags |= PIN_USER | PIN_NOEVICT | PIN_OFFSET_FIXED;
- if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_GTT))
+ if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
pin_flags |= PIN_GLOBAL;
if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
return false;
- if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
+ if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
if (unlikely(i915_vma_pin_fence(vma))) {
i915_vma_unpin(vma);
return false;
}
if (vma->fence)
- exec_flags |= __EXEC_OBJECT_HAS_FENCE;
+ ev->flags |= __EXEC_OBJECT_HAS_FENCE;
}
- *vma->exec_flags = exec_flags | __EXEC_OBJECT_HAS_PIN;
- return !eb_vma_misplaced(entry, vma, exec_flags);
+ ev->flags |= __EXEC_OBJECT_HAS_PIN;
+ return !eb_vma_misplaced(entry, vma, ev->flags);
}
static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
@@
[Intel-gfx] [PATCH 1/3] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT
Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig
option, primarily to allow brave systems to disable the timeout and
solely rely on correct signaling.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.profile | 12
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
drivers/gpu/drm/i915/gem/i915_gem_clflush.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 +--
drivers/gpu/drm/i915/gem/i915_gem_fence.c | 4 ++--
drivers/gpu/drm/i915/i915_config.c | 15 +++
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_request.c| 4 ++--
9 files changed, 38 insertions(+), 10 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_config.c
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index c280b6ae38eb..5d7b440b890d 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -1,3 +1,15 @@
+config DRM_I915_FENCE_TIMEOUT
+ int "Timeout for unsignaled foreign fences"
+ default 1 # milliseconds
+ help
+ When listening to a foreign fence, we install a supplementary timer
+ to ensure that we are always signaled and our userspace is able to
+ make forward progress. This value specifies the timeout used for an
+ unsignaled foreign fence.
+
+ May be 0 to disable the timeout, and rely on the foreign fence being
+ eventually signaled.
+
config DRM_I915_USERFAULT_AUTOSUSPEND
int "Runtime autosuspend delay for userspace GGTT mmaps (ms)"
default 250 # milliseconds
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index ff5c3983efff..51f923e5df47 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -37,6 +37,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# core driver code
i915-y += i915_drv.o \
+ i915_config.o \
i915_irq.o \
i915_getparam.o \
i915_params.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3031e64ee518..54b8243ce986 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15978,7 +15978,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
if (new_plane_state->uapi.fence) { /* explicit fencing */
ret = i915_sw_fence_await_dma_fence(>commit_ready,
new_plane_state->uapi.fence,
- I915_FENCE_TIMEOUT,
+
i915_fence_timeout(dev_priv),
GFP_KERNEL);
if (ret < 0)
return ret;
@@ -16005,7 +16005,8 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
ret = i915_sw_fence_await_reservation(>commit_ready,
obj->base.resv, NULL,
- false, I915_FENCE_TIMEOUT,
+ false,
+
i915_fence_timeout(dev_priv),
GFP_KERNEL);
if (ret < 0)
goto unpin_fb;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index 34be4c0ee7c5..bc0223716906 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -108,7 +108,7 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object
*obj,
if (clflush) {
i915_sw_fence_await_reservation(>base.chain,
obj->base.resv, NULL, true,
- I915_FENCE_TIMEOUT,
+
i915_fence_timeout(to_i915(obj->base.dev)),
I915_FENCE_GFP);
dma_resv_add_excl_fence(obj->base.resv, >base.dma);
dma_fence_work_commit(>base);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 81366aa4812b..5548e3be35c8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -289,8 +289,7 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
i915_gem_object_lock(obj);
err = i915_sw_fence_await_reservation(>wait,
- obj->base.resv, NULL,
- true, I915_FENCE_TIMEOUT,
+
