[Intel-gfx] [PATCH 00/10] drm/i915: Prep work for finishing (de)gamma readout

[Ville Syrjala]

From: Ville Syrjälä 

Add another layer of LUT blobs in order to make gamma
state readout/check possible on ilk-skl. As a bonus we
can also simplify the glk degamma vs. csc mess.

The actual state readout/checker stuff that we're
currently missing will follow later.

Ville Syrjälä (10):
  drm/i915: Remove PLL asserts from .load_luts()
  drm/i915: Split up intel_color_init()
  drm/i915: Simplify the intel_color_init_hooks() if ladder
  drm/i915: Clean up intel_color_init_hooks()
  drm/i915: Change glk_load_degamma_lut() calling convention
  drm/i915: Make ilk_load_luts() deal with degamma
  drm/i915: Introduce crtc_state->{pre,post}_csc_lut
  drm/i915: Assert {pre,post}_csc_lut were assigned sensibly
  drm/i915: Get rid of glk_load_degamma_lut_linear()
  drm/i915: Stop loading linear degammma LUT on glk needlessly

 drivers/gpu/drm/i915/display/intel_atomic.c   |   8 +
 drivers/gpu/drm/i915/display/intel_color.c| 356 ++
 drivers/gpu/drm/i915/display/intel_color.h|   6 +-
 drivers/gpu/drm/i915/display/intel_crtc.c |   3 +-
 .../drm/i915/display/intel_crtc_state_dump.c  |  10 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   9 +-
 .../gpu/drm/i915/display/intel_display_core.h |   5 +
 .../drm/i915/display/intel_display_types.h|   4 +
 .../drm/i915/display/intel_modeset_setup.c|   6 +
 9 files changed, 251 insertions(+), 156 deletions(-)

-- 
2.35.1

[Intel-gfx] [PATCH 03/10] drm/i915: Simplify the intel_color_init_hooks() if ladder

[Ville Syrjala]

From: Ville Syrjälä 

Get rid of the funny hsw vs. ivb extra indentation level in
intel_color_init_hooks().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index ddfe7c257a72..ce8a4be9b292 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2238,12 +2238,11 @@ void intel_color_init_hooks(struct drm_i915_private 
*dev_priv)
dev_priv->display.funcs.color = &skl_color_funcs;
else if (DISPLAY_VER(dev_priv) == 8)
dev_priv->display.funcs.color = &bdw_color_funcs;
-   else if (DISPLAY_VER(dev_priv) == 7) {
-   if (IS_HASWELL(dev_priv))
-   dev_priv->display.funcs.color = 
&hsw_color_funcs;
-   else
-   dev_priv->display.funcs.color = 
&ivb_color_funcs;
-   } else
+   else if (IS_HASWELL(dev_priv))
+   dev_priv->display.funcs.color = &hsw_color_funcs;
+   else if (DISPLAY_VER(dev_priv) == 7)
+   dev_priv->display.funcs.color = &ivb_color_funcs;
+   else
dev_priv->display.funcs.color = &ilk_color_funcs;
}
 }
-- 
2.35.1

[Intel-gfx] [PATCH 02/10] drm/i915: Split up intel_color_init()

[Ville Syrjala]

From: Ville Syrjälä 

intel_color_init() does both device level and crtc level stuff.
Split it up accordingly.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c   | 15 +--
 drivers/gpu/drm/i915/display/intel_color.h   |  4 +++-
 drivers/gpu/drm/i915/display/intel_crtc.c|  3 +--
 drivers/gpu/drm/i915/display/intel_display.c |  1 +
 4 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index bbc56affb3ec..ddfe7c257a72 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2206,13 +2206,21 @@ static const struct intel_color_funcs ilk_color_funcs = 
{
.read_luts = ilk_read_luts,
 };
 
-void intel_color_init(struct intel_crtc *crtc)
+void intel_crtc_color_init(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
bool has_ctm = INTEL_INFO(dev_priv)->display.color.degamma_lut_size != 
0;
 
drm_mode_crtc_set_gamma_size(&crtc->base, 256);
 
+   drm_crtc_enable_color_mgmt(&crtc->base,
+  
INTEL_INFO(dev_priv)->display.color.degamma_lut_size,
+  has_ctm,
+  
INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
+}
+
+void intel_color_init_hooks(struct drm_i915_private *dev_priv)
+{
if (HAS_GMCH(dev_priv)) {
if (IS_CHERRYVIEW(dev_priv)) {
dev_priv->display.funcs.color = &chv_color_funcs;
@@ -2238,9 +2246,4 @@ void intel_color_init(struct intel_crtc *crtc)
} else
dev_priv->display.funcs.color = &ilk_color_funcs;
}
-
-   drm_crtc_enable_color_mgmt(&crtc->base,
-  
INTEL_INFO(dev_priv)->display.color.degamma_lut_size,
-  has_ctm,
-  
INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_color.h 
b/drivers/gpu/drm/i915/display/intel_color.h
index fd873425e082..67702451e2fd 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -10,9 +10,11 @@
 
 struct intel_crtc_state;
 struct intel_crtc;
+struct drm_i915_private;
 struct drm_property_blob;
 
-void intel_color_init(struct intel_crtc *crtc);
+void intel_color_init_hooks(struct drm_i915_private *i915);
+void intel_crtc_color_init(struct intel_crtc *crtc);
 int intel_color_check(struct intel_crtc_state *crtc_state);
 void intel_color_commit_noarm(const struct intel_crtc_state *crtc_state);
 void intel_color_commit_arm(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 6792a9056f46..2d9fc7383bfc 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -365,8 +365,7 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, enum 
pipe pipe)
BIT(DRM_SCALING_FILTER_DEFAULT) 
|

BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
 
-   intel_color_init(crtc);
-
+   intel_crtc_color_init(crtc);
intel_crtc_drrs_init(crtc);
intel_crtc_crc_init(crtc);
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index eb8eaeb19881..a103413cb081 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8326,6 +8326,7 @@ void intel_init_display_hooks(struct drm_i915_private 
*dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
 
+   intel_color_init_hooks(dev_priv);
intel_init_cdclk_hooks(dev_priv);
intel_audio_hooks_init(dev_priv);
 
-- 
2.35.1

[Intel-gfx] [PATCH 01/10] drm/i915: Remove PLL asserts from .load_luts()

[Ville Syrjala]

From: Ville Syrjälä 

.load_luts() potentially runs from the vblank worker, and is
under a deadline to complete within the vblank. Thus we can't
do expesive stuff like talk to the Punit, etc.

To that end get rid of the assert_dsi_pll_enabled() call for
vlv/chv. We'll just have to trust that the PLL is already enabled
here.

And I don't think the normal assert_pll_enabled() really buys us
anything useful on gmch platforms either, so nuke that one too.
We don't have corresponding asserts in the ilk+ codepaths anyway
despite the hardware (IIRC) still requiring the clock to be
enabled when we access the LUT.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 6bda4274eae9..bbc56affb3ec 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -25,9 +25,7 @@
 #include "intel_color.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
-#include "intel_dpll.h"
 #include "intel_dsb.h"
-#include "vlv_dsi_pll.h"
 
 struct intel_color_funcs {
int (*color_check)(struct intel_crtc_state *crtc_state);
@@ -580,11 +578,8 @@ static void i9xx_load_lut_8(struct intel_crtc *crtc,
 static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
 
-   assert_pll_enabled(dev_priv, crtc->pipe);
-
i9xx_load_lut_8(crtc, gamma_lut);
 }
 
@@ -611,14 +606,8 @@ static void i965_load_lut_10p6(struct intel_crtc *crtc,
 static void i965_load_luts(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
 
-   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
-   assert_dsi_pll_enabled(dev_priv);
-   else
-   assert_pll_enabled(dev_priv, crtc->pipe);
-
if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
i9xx_load_lut_8(crtc, gamma_lut);
else
-- 
2.35.1

[Intel-gfx] [PATCH 05/10] drm/i915: Change glk_load_degamma_lut() calling convention

[Ville Syrjala]

From: Ville Syrjälä 

Make glk_load_degamma_lut() more like most everyone else and
pass in the LUT explicitly.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 96687ec30b19..0c73b2ba1283 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -826,13 +826,14 @@ static int glk_degamma_lut_size(struct drm_i915_private 
*i915)
return 35;
 }
 
-static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state)
+static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state,
+const struct drm_property_blob *blob)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   const struct drm_color_lut *lut = blob->data;
+   int i, lut_size = drm_color_lut_size(blob);
enum pipe pipe = crtc->pipe;
-   int i, lut_size = INTEL_INFO(dev_priv)->display.color.degamma_lut_size;
-   const struct drm_color_lut *lut = crtc_state->hw.degamma_lut->data;
 
/*
 * When setting the auto-increment bit, the hardware seems to
@@ -899,6 +900,7 @@ static void glk_load_degamma_lut_linear(const struct 
intel_crtc_state *crtc_stat
 
 static void glk_load_luts(const struct intel_crtc_state *crtc_state)
 {
+   const struct drm_property_blob *degamma_lut = 
crtc_state->hw.degamma_lut;
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
@@ -910,8 +912,8 @@ static void glk_load_luts(const struct intel_crtc_state 
*crtc_state)
 * the degama LUT so that we don't have to reload
 * it every time the pipe CSC is being enabled.
 */
-   if (crtc_state->hw.degamma_lut)
-   glk_load_degamma_lut(crtc_state);
+   if (degamma_lut)
+   glk_load_degamma_lut(crtc_state, degamma_lut);
else
glk_load_degamma_lut_linear(crtc_state);
 
@@ -1043,11 +1045,12 @@ icl_program_gamma_multi_segment(const struct 
intel_crtc_state *crtc_state)
 
 static void icl_load_luts(const struct intel_crtc_state *crtc_state)
 {
+   const struct drm_property_blob *degamma_lut = 
crtc_state->hw.degamma_lut;
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
-   if (crtc_state->hw.degamma_lut)
-   glk_load_degamma_lut(crtc_state);
+   if (degamma_lut)
+   glk_load_degamma_lut(crtc_state, degamma_lut);
 
switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
case GAMMA_MODE_MODE_8BIT:
-- 
2.35.1

[Intel-gfx] [PATCH 09/10] drm/i915: Get rid of glk_load_degamma_lut_linear()

[Ville Syrjala]

From: Ville Syrjälä 

Since we now have a place (pre_csc_lut) to stuff a purely
internal LUT we can replace glk_load_degamma_lut_linear()
with such a thing and just rely on the normal
glk_load_degamma_lut() to load it as well.

drm_mode_config_cleanup() will clean this up for us.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c| 110 +++---
 drivers/gpu/drm/i915/display/intel_color.h|   1 +
 drivers/gpu/drm/i915/display/intel_display.c  |   4 +
 .../gpu/drm/i915/display/intel_display_core.h |   5 +
 4 files changed, 79 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 575d2a23682a..de530bf1aba1 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -557,6 +557,32 @@ static void skl_color_commit_arm(const struct 
intel_crtc_state *crtc_state)
  crtc_state->csc_mode);
 }
 
+static struct drm_property_blob *
+create_linear_lut(struct drm_i915_private *i915, int lut_size)
+{
+   struct drm_property_blob *blob;
+   struct drm_color_lut *lut;
+   int i;
+
+   blob = drm_property_create_blob(&i915->drm,
+   sizeof(struct drm_color_lut) * lut_size,
+   NULL);
+   if (IS_ERR(blob))
+   return NULL;
+
+   lut = blob->data;
+
+   for (i = 0; i < lut_size; i++) {
+   u16 val = 0x * i / (lut_size - 1);
+
+   lut[i].red = val;
+   lut[i].green = val;
+   lut[i].blue = val;
+   }
+
+   return blob;
+}
+
 static void i9xx_load_lut_8(struct intel_crtc *crtc,
const struct drm_property_blob *blob)
 {
@@ -871,53 +897,14 @@ static void glk_load_degamma_lut(const struct 
intel_crtc_state *crtc_state,
intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
 }
 
-static void glk_load_degamma_lut_linear(const struct intel_crtc_state 
*crtc_state)
-{
-   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum pipe pipe = crtc->pipe;
-   int i, lut_size = INTEL_INFO(dev_priv)->display.color.degamma_lut_size;
-
-   /*
-* When setting the auto-increment bit, the hardware seems to
-* ignore the index bits, so we need to reset it to index 0
-* separately.
-*/
-   intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
-   intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe),
- PRE_CSC_GAMC_AUTO_INCREMENT);
-
-   for (i = 0; i < lut_size; i++) {
-   u32 v = (i << 16) / (lut_size - 1);
-
-   intel_de_write_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe), v);
-   }
-
-   /* Clamp values > 1.0. */
-   while (i++ < 35)
-   intel_de_write_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe), 1 << 16);
-
-   intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe), 0);
-}
-
 static void glk_load_luts(const struct intel_crtc_state *crtc_state)
 {
const struct drm_property_blob *pre_csc_lut = crtc_state->pre_csc_lut;
const struct drm_property_blob *post_csc_lut = crtc_state->post_csc_lut;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
-   /*
-* On GLK+ both pipe CSC and degamma LUT are controlled
-* by csc_enable. Hence for the cases where the CSC is
-* needed but degamma LUT is not we need to load a
-* linear degamma LUT. In fact we'll just always load
-* the degama LUT so that we don't have to reload
-* it every time the pipe CSC is being enabled.
-*/
if (pre_csc_lut)
glk_load_degamma_lut(crtc_state, pre_csc_lut);
-   else
-   glk_load_degamma_lut_linear(crtc_state);
 
switch (crtc_state->gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
@@ -1360,11 +1347,17 @@ void intel_color_assert_luts(const struct 
intel_crtc_state *crtc_state)
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
 
/* make sure {pre,post}_csc_lut were correctly assigned */
-   if (DISPLAY_VER(i915) >= 10 || HAS_GMCH(i915)) {
+   if (DISPLAY_VER(i915) >= 11 || HAS_GMCH(i915)) {
drm_WARN_ON(&i915->drm,
crtc_state->pre_csc_lut != 
crtc_state->hw.degamma_lut);
drm_WARN_ON(&i915->drm,
crtc_state->post_csc_lut != 
crtc_state->hw.gamma_lut);
+   } else if (DISPLAY_VER(i915) == 10) {
+   drm_WARN_ON(&i915->drm,
+   crtc_state->pre_csc_lut != 
crtc_state->hw.degamma_lut &&
+   crtc_state->pre_csc_lut != 
i915->display.color.glk_linear_degamma_lut);
+   drm_WARN_ON(&i915->drm,
+   crtc_state->post_csc_lu

[Intel-gfx] [PATCH 08/10] drm/i915: Assert {pre, post}_csc_lut were assigned sensibly

[Ville Syrjala]

From: Ville Syrjälä 

Since we now have the extra step from hw.(de)gamma_lut into
{pre,post}_csc_lut let's make sure we didn't forget to assign
them appropriately. Ie. basically making sure intel_color_check()
was called when necessary (and that it did its job suitable well).

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c   | 20 
 drivers/gpu/drm/i915/display/intel_color.h   |  1 +
 drivers/gpu/drm/i915/display/intel_display.c |  2 ++
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 380f44720fe6..575d2a23682a 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1355,6 +1355,26 @@ static u32 i9xx_gamma_mode(struct intel_crtc_state 
*crtc_state)
return GAMMA_MODE_MODE_10BIT; /* i965+ only */
 }
 
+void intel_color_assert_luts(const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+   /* make sure {pre,post}_csc_lut were correctly assigned */
+   if (DISPLAY_VER(i915) >= 10 || HAS_GMCH(i915)) {
+   drm_WARN_ON(&i915->drm,
+   crtc_state->pre_csc_lut != 
crtc_state->hw.degamma_lut);
+   drm_WARN_ON(&i915->drm,
+   crtc_state->post_csc_lut != 
crtc_state->hw.gamma_lut);
+   } else {
+   drm_WARN_ON(&i915->drm,
+   crtc_state->pre_csc_lut != 
crtc_state->hw.degamma_lut &&
+   crtc_state->pre_csc_lut != 
crtc_state->hw.gamma_lut);
+   drm_WARN_ON(&i915->drm,
+   crtc_state->post_csc_lut != 
crtc_state->hw.degamma_lut &&
+   crtc_state->post_csc_lut != 
crtc_state->hw.gamma_lut);
+   }
+}
+
 static void intel_assign_luts(struct intel_crtc_state *crtc_state)
 {
drm_property_replace_blob(&crtc_state->pre_csc_lut,
diff --git a/drivers/gpu/drm/i915/display/intel_color.h 
b/drivers/gpu/drm/i915/display/intel_color.h
index 67702451e2fd..b76f18e6c452 100644
--- a/drivers/gpu/drm/i915/display/intel_color.h
+++ b/drivers/gpu/drm/i915/display/intel_color.h
@@ -24,5 +24,6 @@ int intel_color_get_gamma_bit_precision(const struct 
intel_crtc_state *crtc_stat
 bool intel_color_lut_equal(struct drm_property_blob *blob1,
   struct drm_property_blob *blob2,
   u32 gamma_mode, u32 bit_precision);
+void intel_color_assert_luts(const struct intel_crtc_state *crtc_state);
 
 #endif /* __INTEL_COLOR_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 20569b6838d1..441811ac0ab0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6906,6 +6906,8 @@ static int intel_atomic_check(struct drm_device *dev,
 
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+   intel_color_assert_luts(new_crtc_state);
+
ret = intel_async_flip_check_hw(state, crtc);
if (ret)
goto fail;
-- 
2.35.1

[Intel-gfx] [PATCH 10/10] drm/i915: Stop loading linear degammma LUT on glk needlessly

[Ville Syrjala]

From: Ville Syrjälä 

Make glk_load_luts() a bit lighter for the common case
where neither the degamma LUT nor pipe CSC are enabled
by not loading the linear degamma LUT. Making .load_luts()
as lightweight as possible is a good idea since it may need
to execute from a vblank worker under tight deadlines.

My earlier reasoning for always loading the linear degamma LUT
was to avoid an extra LUT load when just enabling/disabling the
pipe CSC, but that is nonsense since we load the LUTs on every
flagged color manaement change/modeset anyway (either of which
is needed for a pipe CSC toggle).

We can also get rid of the glk_can_preload_luts() special
case since the presence of the degamma LUT will now always
match csc_enable.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 26 +++---
 1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index de530bf1aba1..a3066d942f58 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1198,24 +1198,6 @@ static bool chv_can_preload_luts(const struct 
intel_crtc_state *new_crtc_state)
return !old_crtc_state->post_csc_lut;
 }
 
-static bool glk_can_preload_luts(const struct intel_crtc_state *new_crtc_state)
-{
-   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
-   struct intel_atomic_state *state =
-   to_intel_atomic_state(new_crtc_state->uapi.state);
-   const struct intel_crtc_state *old_crtc_state =
-   intel_atomic_get_old_crtc_state(state, crtc);
-
-   /*
-* The hardware degamma is active whenever the pipe
-* CSC is active. Thus even if the old state has no
-* software degamma we need to avoid clobbering the
-* linear hardware degamma mid scanout.
-*/
-   return !old_crtc_state->csc_enable &&
-   !old_crtc_state->post_csc_lut;
-}
-
 int intel_color_check(struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
@@ -1622,11 +1604,9 @@ static void glk_assign_luts(struct intel_crtc_state 
*crtc_state)
 * On GLK+ both pipe CSC and degamma LUT are controlled
 * by csc_enable. Hence for the cases where the CSC is
 * needed but degamma LUT is not we need to load a
-* linear degamma LUT. In fact we'll just always load
-* the degama LUT so that we don't have to reload
-* it every time the pipe CSC is being enabled.
+* linear degamma LUT.
 */
-   if (!crtc_state->pre_csc_lut)
+   if (crtc_state->csc_enable && !crtc_state->pre_csc_lut)
drm_property_replace_blob(&crtc_state->pre_csc_lut,
  
i915->display.color.glk_linear_degamma_lut);
 }
@@ -1667,7 +1647,7 @@ static int glk_color_check(struct intel_crtc_state 
*crtc_state)
 
glk_assign_luts(crtc_state);
 
-   crtc_state->preload_luts = glk_can_preload_luts(crtc_state);
+   crtc_state->preload_luts = intel_can_preload_luts(crtc_state);
 
return 0;
 }
-- 
2.35.1

[Intel-gfx] [PATCH 07/10] drm/i915: Introduce crtc_state->{pre, post}_csc_lut

[Ville Syrjala]

From: Ville Syrjälä 

Add an extra remapping step between the logical state of the LUTs
(hw.(de)gamma_lut) as specified via uapi/bigjoiner copy vs.
the actual state of the LUTs programmed into the hardware.

With this we should be finally able finish the (de)gamma
readout/state checker support for the remaining platforms
(ilk-skl) where the same hardware LUT can be positioned
either before or after the pipe CSC unit. Where we position
it depends on factors such as presence of the logical degamma
LUT, RGB vs. YCbCr output, full vs. limited RGB quantization
range.

Without the extra remapping step the state readout doesn't
really know whether the LUT read from the hardware is the
degamma or gamma LUT, and so we is unable to accurately store
it into our crtc state. With the remapping step we know
exactly where to put it given the order of the LUT vs. CSC
in the hardware state.

Only the initial hw->uapi state readout done during driver
load/resume still has the problem of not really knowing
what to do with the LUT(s). But we can just assume 1:1
mapping there and let subsequent commits fix things up.

Another benefit is that we now have a place for purely
internal LUTs, without complicating the bigjoiner uapi->hw
copy logic. This should prove useful for streamlining
glk degamma LUT handling.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_atomic.c   |   8 +
 drivers/gpu/drm/i915/display/intel_color.c| 141 +++---
 .../drm/i915/display/intel_crtc_state_dump.c  |  10 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   2 +-
 .../drm/i915/display/intel_display_types.h|   4 +
 .../drm/i915/display/intel_modeset_setup.c|   6 +
 6 files changed, 114 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 18f0a5ae3bac..6621aa245caf 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -252,6 +252,11 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
if (crtc_state->hw.gamma_lut)
drm_property_blob_get(crtc_state->hw.gamma_lut);
 
+   if (crtc_state->pre_csc_lut)
+   drm_property_blob_get(crtc_state->pre_csc_lut);
+   if (crtc_state->post_csc_lut)
+   drm_property_blob_get(crtc_state->post_csc_lut);
+
crtc_state->update_pipe = false;
crtc_state->disable_lp_wm = false;
crtc_state->disable_cxsr = false;
@@ -274,6 +279,9 @@ static void intel_crtc_put_color_blobs(struct 
intel_crtc_state *crtc_state)
drm_property_blob_put(crtc_state->hw.degamma_lut);
drm_property_blob_put(crtc_state->hw.gamma_lut);
drm_property_blob_put(crtc_state->hw.ctm);
+
+   drm_property_blob_put(crtc_state->pre_csc_lut);
+   drm_property_blob_put(crtc_state->post_csc_lut);
 }
 
 void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index abaa1abab64d..380f44720fe6 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -578,9 +578,9 @@ static void i9xx_load_lut_8(struct intel_crtc *crtc,
 static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
+   const struct drm_property_blob *post_csc_lut = crtc_state->post_csc_lut;
 
-   i9xx_load_lut_8(crtc, gamma_lut);
+   i9xx_load_lut_8(crtc, post_csc_lut);
 }
 
 static void i965_load_lut_10p6(struct intel_crtc *crtc,
@@ -606,12 +606,12 @@ static void i965_load_lut_10p6(struct intel_crtc *crtc,
 static void i965_load_luts(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
+   const struct drm_property_blob *post_csc_lut = crtc_state->post_csc_lut;
 
if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
-   i9xx_load_lut_8(crtc, gamma_lut);
+   i9xx_load_lut_8(crtc, post_csc_lut);
else
-   i965_load_lut_10p6(crtc, gamma_lut);
+   i965_load_lut_10p6(crtc, post_csc_lut);
 }
 
 static void ilk_load_lut_8(struct intel_crtc *crtc,
@@ -648,9 +648,9 @@ static void ilk_load_lut_10(struct intel_crtc *crtc,
 static void ilk_load_luts(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
-   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
-   const struct drm_property_blob *degamma_lut = 
crtc_state->hw.degamma_lut;
-   const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
+   const struct drm_property_blob *post_csc_lut = crtc_state->post_csc_lut;
+   const stru

[Intel-gfx] [PATCH 06/10] drm/i915: Make ilk_load_luts() deal with degamma

[Ville Syrjala]

From: Ville Syrjälä 

Make ilk_load_luts() ready for a degamma lut. Currently we never
have one, but soon we may get one from readout, and I think we
may want to change the state computation such that we may end up
with one even when userspace has simply supplied a gamma lut.

At least the code now follows the path laid out by the ivb/bdw
counterpars.

Reviewed-by: Uma Shankar 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index 0c73b2ba1283..abaa1abab64d 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -649,13 +649,15 @@ static void ilk_load_luts(const struct intel_crtc_state 
*crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
+   const struct drm_property_blob *degamma_lut = 
crtc_state->hw.degamma_lut;
+   const struct drm_property_blob *blob = gamma_lut ?: degamma_lut;
 
switch (crtc_state->gamma_mode) {
case GAMMA_MODE_MODE_8BIT:
-   ilk_load_lut_8(crtc, gamma_lut);
+   ilk_load_lut_8(crtc, blob);
break;
case GAMMA_MODE_MODE_10BIT:
-   ilk_load_lut_10(crtc, gamma_lut);
+   ilk_load_lut_10(crtc, blob);
break;
default:
MISSING_CASE(crtc_state->gamma_mode);
-- 
2.35.1

[Intel-gfx] [PATCH 04/10] drm/i915: Clean up intel_color_init_hooks()

[Ville Syrjala]

From: Ville Syrjälä 

Remove a bunch of pointless curly brackets and do
the s/dev_priv/i915/ while at it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_color.c | 43 +++---
 1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index ce8a4be9b292..96687ec30b19 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -2219,30 +2219,29 @@ void intel_crtc_color_init(struct intel_crtc *crtc)
   
INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
 }
 
-void intel_color_init_hooks(struct drm_i915_private *dev_priv)
+void intel_color_init_hooks(struct drm_i915_private *i915)
 {
-   if (HAS_GMCH(dev_priv)) {
-   if (IS_CHERRYVIEW(dev_priv)) {
-   dev_priv->display.funcs.color = &chv_color_funcs;
-   } else if (DISPLAY_VER(dev_priv) >= 4) {
-   dev_priv->display.funcs.color = &i965_color_funcs;
-   } else {
-   dev_priv->display.funcs.color = &i9xx_color_funcs;
-   }
+   if (HAS_GMCH(i915)) {
+   if (IS_CHERRYVIEW(i915))
+   i915->display.funcs.color = &chv_color_funcs;
+   else if (DISPLAY_VER(i915) >= 4)
+   i915->display.funcs.color = &i965_color_funcs;
+   else
+   i915->display.funcs.color = &i9xx_color_funcs;
} else {
-   if (DISPLAY_VER(dev_priv) >= 11)
-   dev_priv->display.funcs.color = &icl_color_funcs;
-   else if (DISPLAY_VER(dev_priv) == 10)
-   dev_priv->display.funcs.color = &glk_color_funcs;
-   else if (DISPLAY_VER(dev_priv) == 9)
-   dev_priv->display.funcs.color = &skl_color_funcs;
-   else if (DISPLAY_VER(dev_priv) == 8)
-   dev_priv->display.funcs.color = &bdw_color_funcs;
-   else if (IS_HASWELL(dev_priv))
-   dev_priv->display.funcs.color = &hsw_color_funcs;
-   else if (DISPLAY_VER(dev_priv) == 7)
-   dev_priv->display.funcs.color = &ivb_color_funcs;
+   if (DISPLAY_VER(i915) >= 11)
+   i915->display.funcs.color = &icl_color_funcs;
+   else if (DISPLAY_VER(i915) == 10)
+   i915->display.funcs.color = &glk_color_funcs;
+   else if (DISPLAY_VER(i915) == 9)
+   i915->display.funcs.color = &skl_color_funcs;
+   else if (DISPLAY_VER(i915) == 8)
+   i915->display.funcs.color = &bdw_color_funcs;
+   else if (IS_HASWELL(i915))
+   i915->display.funcs.color = &hsw_color_funcs;
+   else if (DISPLAY_VER(i915) == 7)
+   i915->display.funcs.color = &ivb_color_funcs;
else
-   dev_priv->display.funcs.color = &ilk_color_funcs;
+   i915->display.funcs.color = &ilk_color_funcs;
}
 }
-- 
2.35.1

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Add SLPC selftest live_slpc_power (rev2)

[Gupta, Anshuman]

On 9/24/2022 7:31 AM, Patchwork wrote:

*Patch Details*
*Series:*   Add SLPC selftest live_slpc_power (rev2)
*URL:*	https://patchwork.freedesktop.org/series/108900/ 


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


Thanks for patch.
Pushed to drm-intel-gt-next.
Br,
Anshuman.



  CI Bug Log - changes from CI_DRM_12174_full -> Patchwork_108900v2_full


Summary

*SUCCESS*

No regressions found.


Participating hosts (10 -> 9)

Missing (1): shard-tglu


Known issues

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



  IGT changes


Issues hit

  *

igt@gem_exec_balancer@parallel-out-fence:

  o shard-iclb: PASS


 -> SKIP 

 (i915#4525 ) +2 similar issues
  *

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

  o shard-tglb: PASS


 -> FAIL 

 (i915#2842 )
  *

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

  o shard-apl: PASS


 -> FAIL 

 (i915#2842 )
  *

igt@gem_exec_fair@basic-throttle@rcs0:

  o shard-glk: PASS


 -> FAIL 

 (i915#2842 )
  *

igt@gen9_exec_parse@allowed-single:

  o shard-glk: PASS


 -> DMESG-WARN 

 (i915#5566  / i915#716 
)
  *

igt@i915_pm_dc@dc6-psr:

  o shard-iclb: PASS

 
-> FAIL 

 (i915#3989  / i915#454 
)
  *

igt@i915_suspend@sysfs-reader:

  o shard-apl: NOTRUN -> DMESG-WARN


 (i915#180 )
  *

igt@kms_big_fb@linear-32bpp-rotate-270:

  o shard-apl: NOTRUN -> SKIP


 (fdo#109271 ) +43 similar issues
  *

igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:

  o shard-apl: NOTRUN -> SKIP


 (fdo#109271  / i915#3886 
) +2 similar issues
  *

igt@kms_color_chamelium@ctm-red-to-blue:

  o shard-apl: NOTRUN -> SKIP


 (fdo#109271  / fdo#111827 
) +1 similar issue
  *

igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:

  o shard-apl: PASS


 -> DMESG-WARN 

 (i915#180 

Re: [Intel-gfx] [PATCH v4 1/4] drm/i915/guc: Limit scheduling properties to avoid overflow

[Tvrtko Ursulin]

On 29/09/2022 03:18, john.c.harri...@intel.com wrote:

From: John Harrison 

GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values and
then get confused by early timeouts, add limits when setting these
values.

v2: Add helper functions for clamping (review feedback from Tvrtko).
v3: Add a bunch of BUG_ON range checks in addition to the checks
already in the clamping functions (Tvrtko)

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio  (v1)


Acked-by: Tvrtko Ursulin 

Regards,

Tvrtko


---
  drivers/gpu/drm/i915/gt/intel_engine.h|  6 ++
  drivers/gpu/drm/i915/gt/intel_engine_cs.c | 69 +++
  drivers/gpu/drm/i915/gt/sysfs_engines.c   | 25 ---
  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   | 21 ++
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  8 +++
  5 files changed, 119 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 04e435bce79bd..cbc8b857d5f7a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -348,4 +348,10 @@ intel_engine_get_hung_context(struct intel_engine_cs 
*engine)
return engine->hung_ce;
  }
  
+u64 intel_clamp_heartbeat_interval_ms(struct intel_engine_cs *engine, u64 value);

+u64 intel_clamp_max_busywait_duration_ns(struct intel_engine_cs *engine, u64 
value);
+u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs *engine, u64 value);
+u64 intel_clamp_stop_timeout_ms(struct intel_engine_cs *engine, u64 value);
+u64 intel_clamp_timeslice_duration_ms(struct intel_engine_cs *engine, u64 
value);
+
  #endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2ddcad497fa30..8f16955f0821e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -512,6 +512,26 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
}
  
+	/* Cap properties according to any system limits */

+#define CLAMP_PROP(field) \
+   do { \
+   u64 clamp = intel_clamp_##field(engine, engine->props.field); \
+   if (clamp != engine->props.field) { \
+   drm_notice(&engine->i915->drm, \
+  "Warning, clamping %s to %lld to prevent 
overflow\n", \
+  #field, clamp); \
+   engine->props.field = clamp; \
+   } \
+   } while (0)
+
+   CLAMP_PROP(heartbeat_interval_ms);
+   CLAMP_PROP(max_busywait_duration_ns);
+   CLAMP_PROP(preempt_timeout_ms);
+   CLAMP_PROP(stop_timeout_ms);
+   CLAMP_PROP(timeslice_duration_ms);
+
+#undef CLAMP_PROP
+
engine->defaults = engine->props; /* never to change again */
  
  	engine->context_size = intel_engine_context_size(gt, engine->class);

@@ -534,6 +554,55 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
return 0;
  }
  
+u64 intel_clamp_heartbeat_interval_ms(struct intel_engine_cs *engine, u64 value)

+{
+   value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+   return value;
+}
+
+u64 intel_clamp_max_busywait_duration_ns(struct intel_engine_cs *engine, u64 
value)
+{
+   value = min(value, jiffies_to_nsecs(2));
+
+   return value;
+}
+
+u64 intel_clamp_preempt_timeout_ms(struct intel_engine_cs *engine, u64 value)
+{
+   /*
+* NB: The GuC API only supports 32bit values. However, the limit is 
further
+* reduced due to internal calculations which would otherwise overflow.
+*/
+   if (intel_guc_submission_is_wanted(&engine->gt->uc.guc))
+   value = min_t(u64, value, guc_policy_max_preempt_timeout_ms());
+
+   value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+   return value;
+}
+
+u64 intel_clamp_stop_timeout_ms(struct intel_engine_cs *engine, u64 value)
+{
+   value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+   return value;
+}
+
+u64 intel_clamp_timeslice_duration_ms(struct intel_engine_cs *engine, u64 
value)
+{
+   /*
+* NB: The GuC API only supports 32bit values. However, the limit is 
further
+* reduced due to internal calculations which would otherwise overflow.
+*/
+   if (intel_guc_submission_is_wanted(&engine->gt->uc.guc))
+   value = min_t(u64, value, guc_policy_max_exec_quantum_ms());
+
+   value = min_t(u64, value, jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT));
+
+   return value;
+}
+
  static void __setup_engine_capabilities(struct intel_engine_cs *engine)

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Make the heartbeat play nice with long pre-emption timeouts

[Tvrtko Ursulin]

On 29/09/2022 03:18, john.c.harri...@intel.com wrote:

From: John Harrison 

Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence the
next patch will re-enable the timeout but bumped up by an order of
magnitude.

However, the heartbeat might not respect that. Depending upon current
activity, a pre-emption to the heartbeat pulse might not even be
attempted until the last heartbeat period. Which means that only one
period is granted for the pre-emption to occur. With the aforesaid
bump, the pre-emption timeout could be significantly larger than this
heartbeat period.

So adjust the heartbeat code to take the pre-emption timeout into
account. When it reaches the final (high priority) period, it now
ensures the delay before hitting reset is bigger than the pre-emption
timeout.

v2: Fix for selftests which adjust the heartbeat period manually.

Signed-off-by: John Harrison 
---
  .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c 
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index a3698f611f457..823a790a0e2ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -22,9 +22,28 @@
  
  static bool next_heartbeat(struct intel_engine_cs *engine)

  {
+   struct i915_request *rq;
long delay;
  
  	delay = READ_ONCE(engine->props.heartbeat_interval_ms);

+
+   rq = engine->heartbeat.systole;
+
+   if (rq && rq->sched.attr.priority >= I915_PRIORITY_BARRIER &&
+   delay == engine->defaults.heartbeat_interval_ms) {


Maybe I forgot but what is the reason for the check against the default 
heartbeat interval?


Regards,

Tvrtko


+   long longer;
+
+   /*
+* The final try is at the highest priority possible. Up until 
now
+* a pre-emption might not even have been attempted. So make 
sure
+* this last attempt allows enough time for a pre-emption to 
occur.
+*/
+   longer = READ_ONCE(engine->props.preempt_timeout_ms) * 2;
+   longer = intel_clamp_heartbeat_interval_ms(engine, longer);
+   if (longer > delay)
+   delay = longer;
+   }
+
if (!delay)
return false;
  

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: Improve long running compute w/a for GuC submission

[Tvrtko Ursulin]

On 29/09/2022 03:18, john.c.harri...@intel.com wrote:

From: John Harrison 

A workaround was added to the driver to allow compute workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.

However, this does not work well in GuC submission mode. In GuC mode,
the pre-emption timeout is how GuC detects hung contexts and triggers
a per engine reset. Thus, disabling the timeout means also losing all
per engine reset ability. A full GT reset will still occur when the
heartbeat finally expires, but that is a much more destructive and
undesirable mechanism.

The purpose of the workaround is actually to give compute tasks longer
to reach a pre-emption point after a pre-emption request has been
issued. This is necessary because Gen12 does not support mid-thread
pre-emption and compute tasks can have long running threads.

So, rather than disabling the timeout completely, just set it to a
'long' value.

v2: Review feedback from Tvrtko - must hard code the 'long' value
instead of determining it algorithmically. So make it an extra CONFIG
definition. Also, remove the execlist centric comment from the
existing pre-emption timeout CONFIG option given that it applies to
more than just execlists.

Signed-off-by: John Harrison 
Reviewed-by: Daniele Ceraolo Spurio  (v1)
Acked-by: Michal Mrozek 


Acked-by: Tvrtko Ursulin 

Regards,

Tvrtko


---
  drivers/gpu/drm/i915/Kconfig.profile  | 26 +++
  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  9 ++--
  2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.profile 
b/drivers/gpu/drm/i915/Kconfig.profile
index 39328567c2007..7cc38d25ee5c8 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -57,10 +57,28 @@ config DRM_I915_PREEMPT_TIMEOUT
default 640 # milliseconds
help
  How long to wait (in milliseconds) for a preemption event to occur
- when submitting a new context via execlists. If the current context
- does not hit an arbitration point and yield to HW before the timer
- expires, the HW will be reset to allow the more important context
- to execute.
+ when submitting a new context. If the current context does not hit
+ an arbitration point and yield to HW before the timer expires, the
+ HW will be reset to allow the more important context to execute.
+
+ This is adjustable via
+ /sys/class/drm/card?/engine/*/preempt_timeout_ms
+
+ May be 0 to disable the timeout.
+
+ The compiled in default may get overridden at driver probe time on
+ certain platforms and certain engines which will be reflected in the
+ sysfs control.
+
+config DRM_I915_PREEMPT_TIMEOUT_COMPUTE
+   int "Preempt timeout for compute engines (ms, jiffy granularity)"
+   default 7500 # milliseconds
+   help
+ How long to wait (in milliseconds) for a preemption event to occur
+ when submitting a new context to a compute capable engine. If the
+ current context does not hit an arbitration point and yield to HW
+ before the timer expires, the HW will be reset to allow the more
+ important context to execute.
  
  	  This is adjustable via

  /sys/class/drm/card?/engine/*/preempt_timeout_ms
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index fcbccd8d244e9..c1257723d1949 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -508,9 +508,14 @@ static int intel_engine_setup(struct intel_gt *gt, enum 
intel_engine_id id,
engine->props.timeslice_duration_ms =
CONFIG_DRM_I915_TIMESLICE_DURATION;
  
-	/* Override to uninterruptible for OpenCL workloads. */

+   /*
+* Mid-thread pre-emption is not available in Gen12. Unfortunately,
+* some compute workloads run quite long threads. That means they get
+* reset due to not pre-empting in a timely manner. So, bump the
+* pre-emption timeout value to be much higher for compute engines.
+*/
if (GRAPHICS_VER(i915) == 12 && (engine->flags & 
I915_ENGINE_HAS_RCS_REG_STATE))
-   engine->props.preempt_timeout_ms = 0;
+   engine->props.preempt_timeout_ms = 
CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE;
  
  	/* Cap properties according to any system limits */

  #define CLAMP_PROP(field) \

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

[Tvrtko Ursulin]

On 28/09/2022 19:27, John Harrison wrote:

On 9/28/2022 00:19, Tvrtko Ursulin wrote:

On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:

On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote:

On 27/09/2022 07:49, Andrzej Hajda wrote:

On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:

On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on DG2), so 
it should
be avoided if possible. Context reset triggered by context 
removal is a

good example.
With this patch multiple igt tests will not timeout and should 
run faster.


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?

Andi



---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void 
guc_handle_context_reset(struct intel_guc *guc,

  trace_intel_context_reset(ce);
    if (likely(!intel_context_is_banned(ce))) {
-    capture_error_state(guc, ce);
+    if (!intel_context_is_exiting(ce))
+    capture_error_state(guc, ce);


I am not sure here - if we have a persistent context which caused a 
GPU hang I'd expect we'd still want error capture.


What causes the reset in the affected IGTs? Always preemption timeout?


guc_context_replay(ce);


You definitely don't want to replay requests of a context that is 
going away.


My intention was to just avoid error capture, but that's even 
better, only condition change:

-        if (likely(!intel_context_is_banned(ce))) {
+       if (likely(intel_context_is_schedulable(ce)))  {


Yes that helper was intended to be used for contexts which should 
not be scheduled post exit or ban.


Daniele - you say there are some misses in the GuC backend. Should 
most, or even all in intel_guc_submission.c be converted to use 
intel_context_is_schedulable? My idea indeed was that "ban" should 
be a level up from the backends. Backend should only distinguish 
between "should I run this or not", and not the reason.


I think that all of them should be updated, but I'd like Matt B to 
confirm as he's more familiar with the code than me.


Right, that sounds plausible to me as well.

One thing I forgot to mention - the only place where backend can care 
between "schedulable" and "banned" is when it picks the preempt 
timeout for non-schedulable contexts. This is to only apply the strict 
1ms to banned (so bad or naught contexts), while the ones which are 
exiting cleanly get the full preempt timeout as otherwise configured. 
This solves the ugly user experience quirk where GPU resets/errors 
were logged upon exit/Ctrl-C of a well behaving application (using 
non-persistent contexts). Hopefully GuC can match that behaviour so 
customers stay happy.


Regards,

Tvrtko


The whole revoke vs ban thing seems broken to me.

First of all, if the user hits Ctrl+C we need to kill the context off 
immediately. That is a fundamental customer requirement. Render and 
compute engines have a 7.5s pre-emption timeout. The user should not 
have to wait 7.5s for a context to be removed from the system when they 
have explicitly killed it themselves. Even the regular timeout of 640ms 
is borderline a long time to wait. And note that there is an ongoing 
request/requirement to increase that to 1900ms.


Under what circumstances would a user expect anything sensible to happen 
after a Ctrl+C in terms of things finishing their rendering and display 
nice pretty images? They killed the app. They want it dead. We should be 
getting it off the hardware as quickly as possible. If you are really 
concerned about resets causing collateral damage then maybe bump the 
termination timeout from 1ms up to 10ms, maybe at most 100ms. If an app 
is 'well behaved' then it should cleanly exit within 10ms. But if it is 
bad (which is almost certainly the case if the user is manually and 
explicitly killing it) then it needs to be killed because it is not 
going to gracefully exit.


Right.. I had it like that initially (lower timeout - I think 20ms or 
so, patch history on the mailing list would know for sure), but then 
simplified it after review feedback to avoid adding another timeout value.


So it's not at all about any expectation that something 

[Intel-gfx] ✓ Fi.CI.IGT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation

[Patchwork]

== Series Details ==

Series: Fixes integer overflow or integer truncation issues in page lookups, 
ttm place configuration and scatterlist creation
URL   : https://patchwork.freedesktop.org/series/109169/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109169v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 12)
--

  Additional (2): shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@gem_mmap_offset@ptrace@lmem0-fixed} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109169v1/shard-dg1-17/igt@gem_mmap_offset@ptr...@lmem0-fixed.html

  
New tests
-

  New tests have been introduced between CI_DRM_12193_full and 
Patchwork_109169v1_full:

### New IGT tests (39) ###

  * igt@gem_mmap_offset@ptrace@lmem0-fixed:
- Statuses : 1 fail(s)
- Exec time: [0.02] s

  * igt@gem_mmap_offset@ptrace@smem0-fixed:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.40] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.23] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.24] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@empty_lease@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lease_invalid_connector@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_connector@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_revoke@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.26] s

  * igt@kms_lease@lease_revoke@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lessee_list@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@lessee_list@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lessee_list@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lessee_list@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@simple_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.47] s

  * igt@kms_lease@simple_lease@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.26] s

  * igt@kms_lease@simple_lease@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.28] s

  * igt@kms_lease@simple_lease@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.26] s

  * igt@kms_plane_multiple@tiling-y@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.57] s

  * igt@kms_plane_multiple@tiling-y@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.49] s

  * igt@kms_plane_multiple@tiling-y@pipe-c-hdmi-a-3:
- Statuses :

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

[Matthew Auld]

On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:

On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c    | 306 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
 drivers/gpu/drm/i915/i915_driver.c    |   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 112 +++
 10 files changed, 495 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
 gem/i915_gem_ttm_move.o \
 gem/i915_gem_ttm_pm.o \
 gem/i915_gem_userptr.o \
+    gem/i915_gem_vm_bind_object.o \
 gem/i915_gem_wait.o \
 gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct 
i915_execbuffer *eb)

 if (unlikely(IS_ERR(ctx)))
 return PTR_ERR(ctx);
+    if (ctx->vm->vm_bind_mode) {
+    i915_gem_context_put(ctx);
+    return -EOPNOTSUPP;
+    }
+
 eb->gem_context = ctx;
 if (i915_gem_context_has_full_ppgtt(ctx))
 eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h

new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+ START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM 
buffer
+ * objects (BOs) or sections of a BOs at specified GPU virtual 
addresses on a
+ * specified address space (VM). Multiple mappings can map to the 
same physical
+ * pages of an object (aliasing). These mappings (also referred to 
as persistent
+ * mappings) will be persistent across multiple GPU submissions 
(execbuf calls)
+ * issued by the UMD, without user having to provide a list of all 
required

+ * mappings during each submission (as required by older execbuf mode).
+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline out 
fence for

+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via 
I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an address 
space (VM)
+ * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND 
extension.

+ *
+ * VM_BIND/UNBIND ioctl calls executed on different CPU threads 
concurrently
+ * are not ordered. Furthermore, parts of the VM_BI

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Prep work for finishing (de)gamma readout

[Patchwork]

== Series Details ==

Series: drm/i915: Prep work for finishing (de)gamma readout
URL   : https://patchwork.freedesktop.org/series/109229/
State : warning

== Summary ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for iommu: Remove iova cpu hotplugging flushing (rev2)

[Patchwork]

== Series Details ==

Series: iommu: Remove iova cpu hotplugging flushing (rev2)
URL   : https://patchwork.freedesktop.org/series/108880/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_108880v2_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 12)
--

  Additional (2): shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-queues-priority-all:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-iclb6/igt@gem_exec_whis...@basic-queues-priority-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-iclb4/igt@gem_exec_whis...@basic-queues-priority-all.html

  * igt@gem_tiled_wb:
- shard-skl:  NOTRUN -> [TIMEOUT][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl10/igt@gem_tiled_wb.html

  * igt@i915_pm_sseu@full-enable:
- shard-skl:  NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl2/igt@i915_pm_s...@full-enable.html

  * igt@i915_selftest@live@gt_pm:
- shard-skl:  NOTRUN -> [DMESG-FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl10/igt@i915_selftest@live@gt_pm.html

  * {igt@kms_color@ctm-0-75@pipe-b-hdmi-a-3} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][6] +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-dg1-19/igt@kms_color@ctm-0...@pipe-b-hdmi-a-3.html

  * igt@kms_cursor_legacy@cursor-vs-flip@atomic:
- shard-skl:  NOTRUN -> [INCOMPLETE][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl9/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-pwrite:
- shard-tglb: [PASS][8] -> [INCOMPLETE][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-tglb5/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-pwrite.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-pwrite.html

  
 Warnings 

  * igt@runner@aborted:
- shard-skl:  ([FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], 
[FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], 
[FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], 
[FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30]) ([i915#6641]) -> 
([FAIL][31], [FAIL][32]) ([i915#3002] / [i915#4312])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl3/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl1/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl6/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl2/igt@run...@aborted.html
   [28]:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prep work for finishing (de)gamma readout

[Patchwork]

== Series Details ==

Series: drm/i915: Prep work for finishing (de)gamma readout
URL   : https://patchwork.freedesktop.org/series/109229/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12197 -> Patchwork_109229v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (45 -> 45)
--

  Additional (2): fi-rkl-guc fi-tgl-dsi 
  Missing(2): bat-dg2-9 fi-bdw-samus 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_lmem_swapping@basic:
- fi-rkl-guc: NOTRUN -> [SKIP][1] ([i915#4613]) +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-rkl-guc/igt@gem_lmem_swapp...@basic.html

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

  * igt@gem_tiled_pread_basic:
- fi-rkl-guc: NOTRUN -> [SKIP][3] ([i915#3282])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-rkl-guc/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_backlight@basic-brightness:
- fi-rkl-guc: NOTRUN -> [SKIP][4] ([i915#3012])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-rkl-guc/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_rps@basic-api:
- fi-rkl-guc: NOTRUN -> [SKIP][5] ([i915#6621])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-rkl-guc/igt@i915_pm_...@basic-api.html

  * igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-dg1-5:  NOTRUN -> [SKIP][7] ([fdo#111827])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/bat-dg1-5/igt@kms_chamel...@common-hpd-after-suspend.html

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2:  NOTRUN -> [SKIP][10] ([i915#4103])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
- fi-rkl-guc: NOTRUN -> [SKIP][11] ([i915#4103])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-rkl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html

  * igt@kms_force_connector_basic@force-connector-state:
- fi-icl-u2:  NOTRUN -> [WARN][12] ([i915#6008])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html

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

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-dg1-5:  NOTRUN -> [SKIP][15] ([i915#4078])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/bat-dg1-5/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-rkl-guc: NOTRUN -> [SKIP][16] ([i915#1072]) +3 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-rkl-guc/igt@kms_psr@sprite_plane_onoff.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-guc: NOTRUN -> [SKIP][17] ([i915#3555] / [i915#4098])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-rkl-guc/igt@kms_setm...@basic-clone-single-crtc.html
- fi-icl-u2:  NOTRUN -> [SKIP][18] ([i915#3555])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109229v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

[Andrzej Hajda]

On 29.09.2022 10:22, Tvrtko Ursulin wrote:


On 28/09/2022 19:27, John Harrison wrote:

On 9/28/2022 00:19, Tvrtko Ursulin wrote:

On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:

On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote:

On 27/09/2022 07:49, Andrzej Hajda wrote:

On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:

On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on DG2), 
so it should
be avoided if possible. Context reset triggered by context 
removal is a

good example.
With this patch multiple igt tests will not timeout and should 
run faster.


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?

Andi



---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void 
guc_handle_context_reset(struct intel_guc *guc,

  trace_intel_context_reset(ce);
    if (likely(!intel_context_is_banned(ce))) {
-    capture_error_state(guc, ce);
+    if (!intel_context_is_exiting(ce))
+    capture_error_state(guc, ce);


I am not sure here - if we have a persistent context which caused a 
GPU hang I'd expect we'd still want error capture.


What causes the reset in the affected IGTs? Always preemption timeout?


guc_context_replay(ce);


You definitely don't want to replay requests of a context that is 
going away.


My intention was to just avoid error capture, but that's even 
better, only condition change:

-        if (likely(!intel_context_is_banned(ce))) {
+       if (likely(intel_context_is_schedulable(ce)))  {


Yes that helper was intended to be used for contexts which should 
not be scheduled post exit or ban.


Daniele - you say there are some misses in the GuC backend. Should 
most, or even all in intel_guc_submission.c be converted to use 
intel_context_is_schedulable? My idea indeed was that "ban" should 
be a level up from the backends. Backend should only distinguish 
between "should I run this or not", and not the reason.


I think that all of them should be updated, but I'd like Matt B to 
confirm as he's more familiar with the code than me.


Right, that sounds plausible to me as well.

One thing I forgot to mention - the only place where backend can care 
between "schedulable" and "banned" is when it picks the preempt 
timeout for non-schedulable contexts. This is to only apply the 
strict 1ms to banned (so bad or naught contexts), while the ones 
which are exiting cleanly get the full preempt timeout as otherwise 
configured. This solves the ugly user experience quirk where GPU 
resets/errors were logged upon exit/Ctrl-C of a well behaving 
application (using non-persistent contexts). Hopefully GuC can match 
that behaviour so customers stay happy.


Regards,

Tvrtko


The whole revoke vs ban thing seems broken to me.

First of all, if the user hits Ctrl+C we need to kill the context off 
immediately. That is a fundamental customer requirement. Render and 
compute engines have a 7.5s pre-emption timeout. The user should not 
have to wait 7.5s for a context to be removed from the system when 
they have explicitly killed it themselves. Even the regular timeout of 
640ms is borderline a long time to wait. And note that there is an 
ongoing request/requirement to increase that to 1900ms.


Under what circumstances would a user expect anything sensible to 
happen after a Ctrl+C in terms of things finishing their rendering and 
display nice pretty images? They killed the app. They want it dead. We 
should be getting it off the hardware as quickly as possible. If you 
are really concerned about resets causing collateral damage then maybe 
bump the termination timeout from 1ms up to 10ms, maybe at most 100ms. 
If an app is 'well behaved' then it should cleanly exit within 10ms. 
But if it is bad (which is almost certainly the case if the user is 
manually and explicitly killing it) then it needs to be killed because 
it is not going to gracefully exit.


Right.. I had it like that initially (lower timeout - I think 20ms or 
so, patch history on the mailing list would know for sure), but then 
simplified it after review feedback to avoid adding another timeout value.


So it's not a

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Per-crtc/connector DRRS debugfs

[Patchwork]

== Series Details ==

Series: drm/i915: Per-crtc/connector DRRS debugfs
URL   : https://patchwork.freedesktop.org/series/109175/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109175v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 9)
--

  Missing(1): shard-rkl 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-tglb: NOTRUN -> [SKIP][1] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-tglb7/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
- shard-iclb: NOTRUN -> [SKIP][2] +1 similar issue
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-iclb4/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-tglb: [PASS][3] -> [SKIP][4] +32 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-tglb3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-tglb5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-mid:
- shard-iclb: [PASS][5] -> [SKIP][6] +25 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-iclb7/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-mid.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-iclb8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-mid.html

  
 Warnings 

  * igt@kms_plane_alpha_blend@pipe-d-constant-alpha-min:
- shard-iclb: [SKIP][7] ([fdo#109278]) -> [SKIP][8] +6 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-iclb8/igt@kms_plane_alpha_bl...@pipe-d-constant-alpha-min.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-iclb5/igt@kms_plane_alpha_bl...@pipe-d-constant-alpha-min.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#4525])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-iclb6/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@capture-recoverable:
- shard-tglb: NOTRUN -> [SKIP][11] ([i915#6344])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-tglb5/igt@gem_exec_capt...@capture-recoverable.html
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#6344])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-iclb4/igt@gem_exec_capt...@capture-recoverable.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar 
issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-apl1/igt@gem_exec_suspend@basic...@smem.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109175v1/shard-apl1/igt@gem_exec_suspend@basic...@smem.html

  

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

[Tvrtko Ursulin]

On 29/09/2022 10:49, Andrzej Hajda wrote:

On 29.09.2022 10:22, Tvrtko Ursulin wrote:

On 28/09/2022 19:27, John Harrison wrote:

On 9/28/2022 00:19, Tvrtko Ursulin wrote:

On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:

On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote:

On 27/09/2022 07:49, Andrzej Hajda wrote:

On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:

On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on DG2), 
so it should
be avoided if possible. Context reset triggered by context 
removal is a

good example.
With this patch multiple igt tests will not timeout and should 
run faster.


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?

Andi



---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void 
guc_handle_context_reset(struct intel_guc *guc,

  trace_intel_context_reset(ce);
    if (likely(!intel_context_is_banned(ce))) {
-    capture_error_state(guc, ce);
+    if (!intel_context_is_exiting(ce))
+    capture_error_state(guc, ce);


I am not sure here - if we have a persistent context which caused 
a GPU hang I'd expect we'd still want error capture.


What causes the reset in the affected IGTs? Always preemption 
timeout?



guc_context_replay(ce);


You definitely don't want to replay requests of a context that 
is going away.


My intention was to just avoid error capture, but that's even 
better, only condition change:

-        if (likely(!intel_context_is_banned(ce))) {
+       if (likely(intel_context_is_schedulable(ce)))  {


Yes that helper was intended to be used for contexts which should 
not be scheduled post exit or ban.


Daniele - you say there are some misses in the GuC backend. Should 
most, or even all in intel_guc_submission.c be converted to use 
intel_context_is_schedulable? My idea indeed was that "ban" should 
be a level up from the backends. Backend should only distinguish 
between "should I run this or not", and not the reason.


I think that all of them should be updated, but I'd like Matt B to 
confirm as he's more familiar with the code than me.


Right, that sounds plausible to me as well.

One thing I forgot to mention - the only place where backend can 
care between "schedulable" and "banned" is when it picks the preempt 
timeout for non-schedulable contexts. This is to only apply the 
strict 1ms to banned (so bad or naught contexts), while the ones 
which are exiting cleanly get the full preempt timeout as otherwise 
configured. This solves the ugly user experience quirk where GPU 
resets/errors were logged upon exit/Ctrl-C of a well behaving 
application (using non-persistent contexts). Hopefully GuC can match 
that behaviour so customers stay happy.


Regards,

Tvrtko


The whole revoke vs ban thing seems broken to me.

First of all, if the user hits Ctrl+C we need to kill the context off 
immediately. That is a fundamental customer requirement. Render and 
compute engines have a 7.5s pre-emption timeout. The user should not 
have to wait 7.5s for a context to be removed from the system when 
they have explicitly killed it themselves. Even the regular timeout 
of 640ms is borderline a long time to wait. And note that there is an 
ongoing request/requirement to increase that to 1900ms.


Under what circumstances would a user expect anything sensible to 
happen after a Ctrl+C in terms of things finishing their rendering 
and display nice pretty images? They killed the app. They want it 
dead. We should be getting it off the hardware as quickly as 
possible. If you are really concerned about resets causing collateral 
damage then maybe bump the termination timeout from 1ms up to 10ms, 
maybe at most 100ms. If an app is 'well behaved' then it should 
cleanly exit within 10ms. But if it is bad (which is almost certainly 
the case if the user is manually and explicitly killing it) then it 
needs to be killed because it is not going to gracefully exit.


Right.. I had it like that initially (lower timeout - I think 20ms or 
so, patch history on the mailing list would know for sure), but then 
simplified it after review feedback to avoid

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Split up intel_color_init()

[Jani Nikula]

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> intel_color_init() does both device level and crtc level stuff.
> Split it up accordingly.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c   | 15 +--
>  drivers/gpu/drm/i915/display/intel_color.h   |  4 +++-
>  drivers/gpu/drm/i915/display/intel_crtc.c|  3 +--
>  drivers/gpu/drm/i915/display/intel_display.c |  1 +
>  4 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index bbc56affb3ec..ddfe7c257a72 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2206,13 +2206,21 @@ static const struct intel_color_funcs ilk_color_funcs 
> = {
>   .read_luts = ilk_read_luts,
>  };
>  
> -void intel_color_init(struct intel_crtc *crtc)
> +void intel_crtc_color_init(struct intel_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   bool has_ctm = INTEL_INFO(dev_priv)->display.color.degamma_lut_size != 
> 0;
>  
>   drm_mode_crtc_set_gamma_size(&crtc->base, 256);
>  
> + drm_crtc_enable_color_mgmt(&crtc->base,
> +
> INTEL_INFO(dev_priv)->display.color.degamma_lut_size,
> +has_ctm,
> +
> INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
> +}
> +
> +void intel_color_init_hooks(struct drm_i915_private *dev_priv)
> +{
>   if (HAS_GMCH(dev_priv)) {
>   if (IS_CHERRYVIEW(dev_priv)) {
>   dev_priv->display.funcs.color = &chv_color_funcs;
> @@ -2238,9 +2246,4 @@ void intel_color_init(struct intel_crtc *crtc)
>   } else
>   dev_priv->display.funcs.color = &ilk_color_funcs;
>   }
> -
> - drm_crtc_enable_color_mgmt(&crtc->base,
> -
> INTEL_INFO(dev_priv)->display.color.degamma_lut_size,
> -has_ctm,
> -
> INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_color.h 
> b/drivers/gpu/drm/i915/display/intel_color.h
> index fd873425e082..67702451e2fd 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.h
> +++ b/drivers/gpu/drm/i915/display/intel_color.h
> @@ -10,9 +10,11 @@
>  
>  struct intel_crtc_state;
>  struct intel_crtc;
> +struct drm_i915_private;
>  struct drm_property_blob;
>  
> -void intel_color_init(struct intel_crtc *crtc);
> +void intel_color_init_hooks(struct drm_i915_private *i915);
> +void intel_crtc_color_init(struct intel_crtc *crtc);
>  int intel_color_check(struct intel_crtc_state *crtc_state);
>  void intel_color_commit_noarm(const struct intel_crtc_state *crtc_state);
>  void intel_color_commit_arm(const struct intel_crtc_state *crtc_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 6792a9056f46..2d9fc7383bfc 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -365,8 +365,7 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, 
> enum pipe pipe)
>   BIT(DRM_SCALING_FILTER_DEFAULT) 
> |
>   
> BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
>  
> - intel_color_init(crtc);
> -
> + intel_crtc_color_init(crtc);
>   intel_crtc_drrs_init(crtc);
>   intel_crtc_crc_init(crtc);

I'd name all of these like:

intel_color_crtc_init();
intel_drrs_crtc_init();
intel_crc_crtc_init();

I think in gem side the "name functions based on first/context argument"
style has lead to serious problems wrt code organization. They still
stick to it, but I can't make heads or tails where function definitions
or declarations are supposed to be placed or found.

BR,
Jani.


>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index eb8eaeb19881..a103413cb081 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8326,6 +8326,7 @@ void intel_init_display_hooks(struct drm_i915_private 
> *dev_priv)
>   if (!HAS_DISPLAY(dev_priv))
>   return;
>  
> + intel_color_init_hooks(dev_priv);
>   intel_init_cdclk_hooks(dev_priv);
>   intel_audio_hooks_init(dev_priv);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

[Matthew Auld]

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   5 +
  drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
  .../drm/i915/gem/i915_gem_vm_bind_object.c| 306 ++
  drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
  drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
  drivers/gpu/drm/i915/i915_driver.c|   3 +
  drivers/gpu/drm/i915/i915_vma.c   |   1 +
  drivers/gpu/drm/i915/i915_vma_types.h |  14 +
  include/uapi/drm/i915_drm.h   | 112 +++
  10 files changed, 495 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
gem/i915_gem_ttm_move.o \
gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
+   gem/i915_gem_vm_bind_object.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
  i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
  
+	if (ctx->vm->vm_bind_mode) {

+   i915_gem_context_put(ctx);
+   return -EOPNOTSUPP;
+   }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
+ * objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
+ * specified address space (VM). Multiple mappings can map to the same physical
+ * pages of an object (aliasing). These mappings (also referred to as 
persistent
+ * mappings) will be persistent across multiple GPU submissions (execbuf calls)
+ * issued by the UMD, without user having to provide a list of all required
+ * mappings during each submission (as required by older execbuf mode).
+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an address space (VM)
+ * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
+ *
+ * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
+ * are not ordered. Furthermore, parts of the VM_BIND/UNBIND operations can be
+ * done a

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

[Matthew Auld]

On 29/09/2022 10:03, Matthew Auld wrote:

On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:

On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c    | 306 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
 drivers/gpu/drm/i915/i915_driver.c    |   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 112 +++
 10 files changed, 495 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
 gem/i915_gem_ttm_move.o \
 gem/i915_gem_ttm_pm.o \
 gem/i915_gem_userptr.o \
+    gem/i915_gem_vm_bind_object.o \
 gem/i915_gem_wait.o \
 gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct 
i915_execbuffer *eb)

 if (unlikely(IS_ERR(ctx)))
 return PTR_ERR(ctx);
+    if (ctx->vm->vm_bind_mode) {
+    i915_gem_context_put(ctx);
+    return -EOPNOTSUPP;
+    }
+
 eb->gem_context = ctx;
 if (i915_gem_context_has_full_ppgtt(ctx))
 eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h

new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+ START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM 
buffer
+ * objects (BOs) or sections of a BOs at specified GPU virtual 
addresses on a
+ * specified address space (VM). Multiple mappings can map to the 
same physical
+ * pages of an object (aliasing). These mappings (also referred to 
as persistent
+ * mappings) will be persistent across multiple GPU submissions 
(execbuf calls)
+ * issued by the UMD, without user having to provide a list of all 
required
+ * mappings during each submission (as required by older execbuf 
mode).

+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline out 
fence for

+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via 
I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an address 
space (VM)
+ * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND 
extension.

+ *
+ * VM_BIND/UNBIND ioctl calls executed on different CPU threads 
concurrently
+ * are n

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Flush to global observation point before breadcrumb write

[Andi Shyti]

Hi,

>Series: drm/i915/gt: Flush to global observation point before
>breadcrumb write
>URL: [1]https://patchwork.freedesktop.org/series/109133/
>State: failure
>Details:
>[2]https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109133v1/index.ht
>ml
> 
>  CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109133v1_full
> 
> Summary
> 
>FAILURE
> 
>Serious unknown changes coming with Patchwork_109133v1_full absolutely
>need to be
>verified manually.
> 
>If you think the reported changes have nothing to do with the changes
>introduced in Patchwork_109133v1_full, please notify your bug team to
>allow them
>to document this new failure mode, which will reduce false positives in
>CI.
> 
> Participating hosts (10 -> 10)
> 
>No changes in participating hosts
> 
> Possible new issues
> 
>Here are the unknown changes that may have been introduced in
>Patchwork_109133v1_full:
> 
>   IGT changes
> 
> Possible regressions
> 
>  * igt@kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling
>@pipe-a-valid-mode:
>   + shard-tglb: [3]PASS -> [4]INCOMPLETE

This looks a false positive to me, not even an unrelated failure.
Can anyone from display have a look and confirm, please?

Andi

[Intel-gfx] [PATCH 0/5] drm/i915/mtl: Add C10 support

[Mika Kahola]

PHY programming support for message bus and phy programming.
Updates for HDMI programming and vswing tables.

Radhakrishna Sripada (5):
  drm/i915/mtl: Add Support for C10,C20 PHY Message Bus
  drm/i915/mtl: Add PLL programming support for C10 phy
  drm/i915/mtl: Add support for C10 phy programming
  drm/i915/mtl: Add C10 phy programming for HDMI
  drm/i915/mtl: Add vswing programming for C10 phys

 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 1300 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |  155 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   26 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|   36 +-
 .../drm/i915/display/intel_ddi_buf_trans.h|6 +
 drivers/gpu/drm/i915/display/intel_display.c  |1 +
 .../drm/i915/display/intel_display_power.c|3 +-
 .../i915/display/intel_display_power_map.c|1 +
 .../i915/display/intel_display_power_well.c   |2 +-
 .../drm/i915/display/intel_display_types.h|6 +
 drivers/gpu/drm/i915/display/intel_dp.c   |   15 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |   20 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |5 +-
 .../drm/i915/display/intel_modeset_verify.c   |2 +
 drivers/gpu/drm/i915/i915_reg.h   |  142 +
 drivers/gpu/drm/i915/intel_pm.c   | 5066 -
 18 files changed, 1714 insertions(+), 5075 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h
 delete mode 100644 drivers/gpu/drm/i915/intel_pm.c

-- 
2.34.1

[Intel-gfx] [PATCH 3/5] drm/i915/mtl: Add support for C10 phy programming

[Mika Kahola]

From: Radhakrishna Sripada 

Add sequences for C10 phy enable/disable phy lane reset,
powerdown change sequence and phy lane programming.

Bspec: 64539, 67636, 65451, 65450, 64568

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola  (v9)
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 352 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  17 +
 drivers/gpu/drm/i915/display/intel_ddi.c |   2 +
 drivers/gpu/drm/i915/display/intel_dp.c  |  15 +-
 drivers/gpu/drm/i915/i915_reg.h  |  82 +
 5 files changed, 464 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 2f401116d1d0..6ba11cd7cd75 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -526,9 +526,9 @@ void intel_c10mpllb_readout_hw_state(struct intel_encoder 
*encoder,
 tx0, cmn, phy_name(phy));
 }
 
-__maybe_unused static void intel_c10_pll_program(struct drm_i915_private *i915,
-const struct intel_crtc_state 
*crtc_state,
-struct intel_encoder *encoder)
+static void intel_c10_pll_program(struct drm_i915_private *i915,
+ const struct intel_crtc_state *crtc_state,
+ struct intel_encoder *encoder)
 {
const struct intel_c10mpllb_state *pll_state = 
&crtc_state->c10mpllb_state;
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
@@ -633,6 +633,352 @@ int intel_c10mpllb_calc_port_clock(struct intel_encoder 
*encoder,
 10 << (tx_clk_div + 16));
 }
 
+#define PHY_LANES_VAL_ARG(FIELD, lanes, arg)   ({u32 __val; switch(lanes) {\
+ case INTEL_CX0_BOTH_LANES:
\
+   __val = 
((XELPDP_LANE0_##FIELD(arg)) |\
+   
(XELPDP_LANE1_##FIELD(arg))); \
+   break;  
\
+ case INTEL_CX0_LANE0: 
\
+   __val = 
(XELPDP_LANE0_##FIELD(arg));\
+   break;  
\
+ case INTEL_CX0_LANE1: 
\
+   __val = 
(XELPDP_LANE1_##FIELD(arg));\
+   break;  \
+}; __val; })
+
+#define PHY_LANES_VAL(FIELD, lanes)({u32 __val; switch(lanes) {\
+ case INTEL_CX0_BOTH_LANES:
\
+   __val = 
(XELPDP_LANE0_##FIELD | \
+   
XELPDP_LANE1_##FIELD); \
+   break;  
\
+ case INTEL_CX0_LANE0: 
\
+   __val = 
(XELPDP_LANE0_##FIELD);  \
+   break;  
\
+ case INTEL_CX0_LANE1: 
\
+   __val = 
(XELPDP_LANE1_##FIELD);\
+   break;  \
+}; __val; })
+
+static void intel_program_port_clock_ctl(struct intel_encoder *encoder,
+const struct intel_crtc_state 
*crtc_state,
+bool lane_reversal)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp;
+   bool ssc_enabled;
+   u32 val = 0;
+
+   intel_de_rmw(i915, XELPDP_PORT_BUF_CTL1(encoder->port), 
XELPDP_PORT_REVERSAL,
+lane_reversal ? XELPDP_PORT_REVERSAL : 0);
+
+   if (lane_reversal)
+   val |= XELPDP_LANE1_PHY_CLOCK_SELECT;
+
+   val |= XELPDP_FORWARD_CLOCK_UNGATE;
+   val |= XELPDP_DDI_CLOCK_SELECT(XELPDP_DDI_CLOCK_SELECT_MAXPCLK);
+
+   if (intel_crtc_has_dp_encoder(crtc_state)) {
+   intel_dp = enc_to_intel_dp(encoder);
+   ssc_enabled = intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
+ DP_MAX_DOWNSPREAD_0_5;
+
+   /* TODO: DP2.0 10G and 20G rates enable MPLLA*/
+   val |= ssc_enabled ? XELPDP_SSC_ENABLE_PLLB : 0;
+   }
+   intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->por

[Intel-gfx] [PATCH 5/5] drm/i915/mtl: Add vswing programming for C10 phys

[Mika Kahola]

From: Radhakrishna Sripada 

C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
Program the levels directly to the fields in the VDR Registers.

Bspec: 65449

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 157 +++---
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   8 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   4 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|  36 +++-
 .../drm/i915/display/intel_ddi_buf_trans.h|   6 +
 .../i915/display/intel_display_power_map.c|   1 +
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 7 files changed, 187 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index a08788d2a3bc..bba3c4579cfa 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -4,12 +4,24 @@
  */
 
 #include "intel_cx0_phy.h"
+#include "intel_ddi.h"
+#include "intel_ddi_buf_trans.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
 #include "intel_panel.h"
+#include "intel_psr.h"
 #include "intel_uncore.h"
 
+static void
+assert_dc_off(struct drm_i915_private *i915)
+{
+   bool enabled;
+
+   enabled = intel_display_power_is_enabled(i915, POWER_DOMAIN_DC_OFF);
+   drm_WARN_ON(&i915->drm, !enabled);
+}
+
 static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
 {
enum phy phy = intel_port_to_phy(i915, port);
@@ -37,6 +49,8 @@ static u8 intel_cx0_read(struct drm_i915_private *i915, enum 
port port,
u32 val = 0;
int attempts = 0;
 
+   assert_dc_off(i915);
+
 retry:
if (attempts == 3) {
drm_err_once(&i915->drm, "PHY %c Read %04x failed after %d 
retries. Status: 0x%x\n", phy_name(phy), addr, attempts, val ?: 0);
@@ -126,6 +140,8 @@ static void __intel_cx0_write(struct drm_i915_private 
*i915, enum port port,
enum phy phy = intel_port_to_phy(i915, port);
int attempts = 0;
 
+   assert_dc_off(i915);
+
 retry:
if (attempts == 3) {
drm_err_once(&i915->drm, "PHY %c Write %04x failed after %d 
retries.\n", phy_name(phy), addr, attempts);
@@ -204,6 +220,76 @@ static void intel_cx0_rmw(struct drm_i915_private *i915, 
enum port port,
}
 }
 
+/*
+ * Prepare HW for CX0 phy transactions.
+ *
+ * It is required that PSR and DC5/6 are disabled before any CX0 message
+ * bus transaction is executed.
+ */
+static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder 
*encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_pause(intel_dp);
+   return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
+}
+
+static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder, 
intel_wakeref_t wakeref)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_resume(intel_dp);
+   intel_display_power_put(i915, POWER_DOMAIN_DC_OFF, wakeref);
+}
+
+void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+   bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
+   enum intel_cx0_lanes master_lane = lane_reversal ? INTEL_CX0_LANE1 :
+INTEL_CX0_LANE0;
+   const struct intel_ddi_buf_trans *trans;
+   intel_wakeref_t wakeref;
+   int n_entries, ln;
+
+   wakeref = intel_cx0_phy_transaction_begin(encoder);
+
+   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
+   if (drm_WARN_ON_ONCE(&i915->drm, !trans))
+   return;
+
+   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+ 0, C10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);
+
+   for (ln = 0; ln < 4; ln++) {
+   int level = intel_ddi_level(encoder, crtc_state, ln);
+   int lane, tx;
+
+   lane = ln / 2;
+   tx = ln % 2 + 1;
+
+   intel_cx0_rmw(i915, encoder->port, lane, PHY_CX0_TX_CONTROL(tx, 
2),
+ C10_PHY_VSWING_PREEMPH_MASK,
+ 
C10_PHY_VSWING_PREEMPH(trans->entries[level].direct.preemph),
+ MB_WRITE_COMMITTED);
+   intel_cx0_rmw(i915, encoder->port, lane, PHY_CX0_TX_CONTROL(tx, 
8),
+ C10_PHY_VSWING_LEVEL_MASK,
+ 
C10_PHY_VSWING_LEVEL(trans->entries[l

[Intel-gfx] [PATCH 2/5] drm/i915/mtl: Add PLL programming support for C10 phy

[Mika Kahola]

From: Radhakrishna Sripada 

XELPDP has C10 phys to drive output to the EDP and the native output
from the display engine. Add structures, programming hardware state
readout logic. Port clock calculations are similar to DG2. Use the DG2
formulae to calculate the port clock but use the relevant pll signals.
Note: PHY lane 0 is always used for PLL programming.

Bspec: 64568, 64539, 67636

Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 516 +-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  | 128 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |  20 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   1 +
 .../drm/i915/display/intel_display_power.c|   3 +-
 .../i915/display/intel_display_power_well.c   |   2 +-
 .../drm/i915/display/intel_display_types.h|   6 +
 drivers/gpu/drm/i915/display/intel_dpll.c |  20 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |   2 +-
 .../drm/i915/display/intel_modeset_verify.c   |   2 +
 10 files changed, 690 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 7930b0255cfa..2f401116d1d0 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -3,7 +3,11 @@
  * Copyright © 2021 Intel Corporation
  */
 
+#include "intel_cx0_phy.h"
 #include "intel_de.h"
+#include "intel_display_types.h"
+#include "intel_dp.h"
+#include "intel_panel.h"
 #include "intel_uncore.h"
 
 static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
@@ -26,7 +30,7 @@ static void intel_cx0_bus_reset(struct drm_i915_private 
*i915, enum port port, i
return;
 }
 
-__maybe_unused static u8 intel_cx0_read(struct drm_i915_private *i915, enum 
port port,
+static u8 intel_cx0_read(struct drm_i915_private *i915, enum port port,
 int lane, u16 addr)
 {
enum phy phy = intel_port_to_phy(i915, port);
@@ -116,8 +120,8 @@ static int intel_cx0_wait_cwrite_ack(struct 
drm_i915_private *i915,
return 0;
 }
 
-__maybe_unused static void intel_cx0_write(struct drm_i915_private *i915, enum 
port port,
-   int lane, u16 addr, u8 data, bool committed)
+static void __intel_cx0_write(struct drm_i915_private *i915, enum port port,
+ int lane, u16 addr, u8 data, bool committed)
 {
enum phy phy = intel_port_to_phy(i915, port);
int attempts = 0;
@@ -166,8 +170,19 @@ __maybe_unused static void intel_cx0_write(struct 
drm_i915_private *i915, enum p
return;
 }
 
-__maybe_unused static void intel_cx0_rmw(struct drm_i915_private *i915, enum 
port port,
- int lane, u16 addr, u8 clear, u8 set, bool committed)
+static void intel_cx0_write(struct drm_i915_private *i915, enum port port,
+   int lane, u16 addr, u8 data, bool committed)
+{
+   if (lane == INTEL_CX0_BOTH_LANES) {
+   __intel_cx0_write(i915, port, INTEL_CX0_LANE0, addr, data, 
committed);
+   __intel_cx0_write(i915, port, INTEL_CX0_LANE1, addr, data, 
committed);
+   } else {
+   __intel_cx0_write(i915, port, lane, addr, data, committed);
+   }
+}
+
+static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
+   int lane, u16 addr, u8 clear, u8 set, bool 
committed)
 {
u8 old, val;
 
@@ -177,3 +192,494 @@ __maybe_unused static void intel_cx0_rmw(struct 
drm_i915_private *i915, enum por
if (val != old)
intel_cx0_write(i915, port, lane, addr, val, committed);
 }
+
+static void intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
+ int lane, u16 addr, u8 clear, u8 set, bool committed)
+{
+   if (lane == INTEL_CX0_BOTH_LANES) {
+   __intel_cx0_rmw(i915, port, INTEL_CX0_LANE0, addr, clear, set, 
committed);
+   __intel_cx0_rmw(i915, port, INTEL_CX0_LANE1, addr, clear, set, 
committed);
+   } else {
+   __intel_cx0_rmw(i915, port, lane, addr, clear, set, committed);
+   }
+}
+
+/*
+ * Basic DP link rates with 38.4 MHz reference clock.
+ * Note: The tables below are with SSC. In non-ssc
+ * registers 0xC04 to 0xC08(pll[4] to pll[8]) will be
+ * programmed 0.
+ */
+
+static const struct intel_c10mpllb_state mtl_c10_dp_rbr = {
+   .clock = 162000,
+   .pll[0] = 0xB4,
+   .pll[1] = 0,
+   .pll[2] = 0x30,
+   .pll[3] = 0x1,
+   .pll[4] = 0x26,
+   .pll[5] = 0x0C,
+   .pll[6] = 0x98,
+   .pll[7] = 0x46,
+   .pll[8] = 0x1,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0xC0,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0x2,
+   .pll[16] = 0x84,
+   .pll[17] = 0x4F,

[Intel-gfx] [PATCH 4/5] drm/i915/mtl: Add C10 phy programming for HDMI

[Mika Kahola]

From: Radhakrishna Sripada 

Like DG2, we still don't have a proper algorithm that can be used
for calculating PHY settings, but we do have tables of register
values for a handful of the more common link rates. Some support is
better than none, so let's go ahead and add/use these tables when we
can, and also add some logic to hdmi_port_clock_valid() to filter the
modelist to just the modes we can actually support with these link
rates.

Hopefully we'll have a proper / non-encumbered algorithm to calculate
these registers by the time we upstream and we'll be able to replace
this patch with something more general purpose.

Bspec: 64568

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 168 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |   2 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|   5 +-
 3 files changed, 170 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 6ba11cd7cd75..a08788d2a3bc 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -448,6 +448,152 @@ static const struct intel_c10mpllb_state * const 
mtl_c10_edp_tables[] = {
NULL,
 };
 
+/*
+ * HDMI link rates with 38.4 MHz reference clock.
+ */
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_25_175 = {
+   .clock = 25175,
+   .pll[0] = 0x4,
+   .pll[1] = 0,
+   .pll[2] = 0xB2,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xD,
+   .pll[16] = 0x6,
+   .pll[17] = 0x8F,
+   .pll[18] = 0x84,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_27_0 = {
+   .clock = 27000,
+   .pll[0] = 0x34,
+   .pll[1] = 0,
+   .pll[2] = 0xC0,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x80,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xD,
+   .pll[16] = 0x6,
+   .pll[17] = 0xCF,
+   .pll[18] = 0x84,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_74_25 = {
+   .clock = 74250,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xB,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_148_5 = {
+   .clock = 148500,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xA,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_594 = {
+   .clock = 594000,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0x8,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state * const mtl_c10_hdmi_tables[] = {
+   &mtl_c10_hdmi_25_175,
+   &mtl_c10_hdmi_27_0,
+   &mtl_c10_hdmi_74_25,
+   &mtl_c10_hdmi_148_5,
+   &mtl_c10_hdmi_594,
+   NULL,
+};
+
+int intel_c10_phy_check_hdmi_link_rate(int clock)
+{
+   const struct intel_c10mpllb_state * const *tables = mtl_c10_hdmi_tables;
+   int i;
+
+   for (i = 0; tables[i]; i++) {
+   if (clock == tables[i]->clock)
+   return MODE_OK;
+   }
+
+   return MODE_CLOCK_RANGE;
+}
+
 static const struct intel_c10mpllb_state * const *
 intel_c10_mpllb_tables_get(struct intel_crtc_state *crtc_state,
   struct intel_encoder *encoder)
@@ -457,9 +603,10 @@ intel_c10_mpllb_tables_get(struct intel_crtc_state 
*crtc_state,
r

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for iommu: Remove iova cpu hotplugging flushing (rev2)

[Janusz Krzysztofik]

On Thursday, 29 September 2022 11:35:23 CEST Patchwork wrote:
> == Series Details ==
> 
> Series: iommu: Remove iova cpu hotplugging flushing (rev2)
> URL   : https://patchwork.freedesktop.org/series/108880/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_108880v2_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_108880v2_full absolutely need 
> to be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_108880v2_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (10 -> 12)
> --
> 
>   Additional (2): shard-dg1 shard-tglu 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_108880v2_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_exec_whisper@basic-queues-priority-all:
> - shard-iclb: [PASS][1] -> [INCOMPLETE][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-iclb6/igt@gem_exec_whis...@basic-queues-priority-all.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-iclb4/igt@gem_exec_whis...@basic-queues-priority-all.html
> 
>   * igt@gem_tiled_wb:
> - shard-skl:  NOTRUN -> [TIMEOUT][3]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl10/igt@gem_tiled_wb.html
> 
>   * igt@i915_pm_sseu@full-enable:
> - shard-skl:  NOTRUN -> [FAIL][4]
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl2/igt@i915_pm_s...@full-enable.html
> 
>   * igt@i915_selftest@live@gt_pm:
> - shard-skl:  NOTRUN -> [DMESG-FAIL][5]
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl10/igt@i915_selftest@live@gt_pm.html
> 
>   * {igt@kms_color@ctm-0-75@pipe-b-hdmi-a-3} (NEW):
> - {shard-dg1}:NOTRUN -> [FAIL][6] +1 similar issue
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-dg1-19/igt@kms_color@ctm-0...@pipe-b-hdmi-a-3.html
> 
>   * igt@kms_cursor_legacy@cursor-vs-flip@atomic:
> - shard-skl:  NOTRUN -> [INCOMPLETE][7]
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-skl9/igt@kms_cursor_legacy@cursor-vs-f...@atomic.html
> 
>   * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-pwrite:
> - shard-tglb: [PASS][8] -> [INCOMPLETE][9]
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-tglb5/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-pwrite.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v2/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-pwrite.html

I've identified all of the above as known issues, CI filters will be updated 
and results re-reported.

Thanks,
Janusz

> 
>   
>  Warnings 
> 
>   * igt@runner@aborted:
> - shard-skl:  ([FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], 
> [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], 
> [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], 
> [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30]) ([i915#6641]) -> 
> ([FAIL][31], [FAIL][32]) ([i915#3002] / [i915#4312])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl3/igt@run...@aborted.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl1/igt@run...@aborted.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl10/igt@run...@aborted.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl9/igt@run...@aborted.html
>[19]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
>[20]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl4/igt@run...@aborted.html
>[21]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl6/igt@run...@aborted.html
>[22]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@aborted.html
>[23]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-skl7/igt@run...@

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload

[Andi Shyti]

Hi Nirmoy,

On Fri, Sep 23, 2022 at 09:35:14AM +0200, Nirmoy Das wrote:
> i915_gem_drain_freed_objects() might not be enough to
> free all the objects and RCU delayed work might get
> scheduled after the i915 device struct gets freed.
> 
> Call i915_gem_drain_workqueue() to catch all RCU delayed work.
> 
> Suggested-by: Chris Wilson 
> Acked-by: Tvrtko Ursulin 
> Signed-off-by: Nirmoy Das 

pushed to drm-intel-gt-next

Thanks,
Andi

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload

[Das, Nirmoy]

On 9/29/2022 1:32 PM, Andi Shyti wrote:

Hi Nirmoy,

On Fri, Sep 23, 2022 at 09:35:14AM +0200, Nirmoy Das wrote:

i915_gem_drain_freed_objects() might not be enough to
free all the objects and RCU delayed work might get
scheduled after the i915 device struct gets freed.

Call i915_gem_drain_workqueue() to catch all RCU delayed work.

Suggested-by: Chris Wilson 
Acked-by: Tvrtko Ursulin 
Signed-off-by: Nirmoy Das 

pushed to drm-intel-gt-next



Thanks, Andi!



Thanks,
Andi

[Intel-gfx] [PATCH v5] drm/i915/mtl: enable local stolen memory

[Aravind Iddamsetty]

As an integrated GPU, MTL does not have local memory and HAS_LMEM()
returns false.  However the platform's stolen memory is presented via
BAR2 (i.e., the BAR we traditionally consider to be the GMADR on IGFX)
and should be managed by the driver the same way that local memory is
on dgpu platforms (which includes setting the "lmem" bit on page table
entries).  We use the term "local stolen memory" to refer to this
model.

The major difference from the traditional BAR2 (GMADR) is that
the stolen area is mapped via the BAR2 while in the former BAR2 is an
aperture into the GTT VA through which access are made into stolen area.

BSPEC: 53098, 63830

v2:
1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas
(Jani, Lucas)
2. drop lmembar_is_igpu_stolen
3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas)

v3:(Jani)
1. rename get_mtl_gms_size to mtl_get_gms_size
2. define register for MMIO address

v4:(Matt)
1. Use REG_FIELD_GET to read GMS value
2. replace the calculations with SZ_256M/SZ_8M

v5: Include more details to commit message on how it is different from
earlier platforms (Anshuman)

Cc: Matt Roper 
Cc: Lucas De Marchi 
Cc: Jani Nikula 

Signed-off-by: CQ Tang 
Signed-off-by: Aravind Iddamsetty 
Original-author: CQ Tang
---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 83 ++
 drivers/gpu/drm/i915/gt/intel_ggtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  3 +
 drivers/gpu/drm/i915/i915_reg.h|  4 ++
 4 files changed, 76 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c5a4035c99cd..910086974454 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,9 +77,9 @@ void i915_gem_stolen_remove_node(struct drm_i915_private 
*i915,
mutex_unlock(&i915->mm.stolen_lock);
 }
 
-static bool valid_stolen_size(struct resource *dsm)
+static bool valid_stolen_size(struct drm_i915_private *i915, struct resource 
*dsm)
 {
-   return dsm->start != 0 && dsm->end > dsm->start;
+   return (dsm->start != 0 || HAS_BAR2_SMEM_STOLEN(i915)) && dsm->end > 
dsm->start;
 }
 
 static int adjust_stolen(struct drm_i915_private *i915,
@@ -88,7 +88,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
 
-   if (!valid_stolen_size(dsm))
+   if (!valid_stolen_size(i915, dsm))
return -EINVAL;
 
/*
@@ -135,7 +135,7 @@ static int adjust_stolen(struct drm_i915_private *i915,
}
}
 
-   if (!valid_stolen_size(dsm))
+   if (!valid_stolen_size(i915, dsm))
return -EINVAL;
 
return 0;
@@ -149,8 +149,11 @@ static int request_smem_stolen(struct drm_i915_private 
*i915,
/*
 * With stolen lmem, we don't need to request system memory for the
 * address range since it's local to the gpu.
+*
+* Starting MTL, in IGFX devices the stolen memory is exposed via
+* BAR2 and shall be considered similar to stolen lmem.
 */
-   if (HAS_LMEM(i915))
+   if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
return 0;
 
/*
@@ -385,8 +388,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private 
*i915,
 
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
 
-   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -404,6 +405,12 @@ static void icl_get_stolen_reserved(struct 
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+   if (HAS_BAR2_SMEM_STOLEN(i915))
+   /* the base is initialized to stolen top so subtract size to 
get base */
+   *base -= *size;
+   else
+   *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
 }
 
 /*
@@ -833,6 +840,29 @@ static const struct intel_memory_region_ops 
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
 };
 
+static int mtl_get_gms_size(struct intel_uncore *uncore)
+{
+   u16 ggc, gms;
+
+   ggc = intel_uncore_read16(uncore, GGC);
+
+   /* check GGMS, should be fixed 0x3 (8MB) */
+   if ((ggc & GGMS_MASK) != GGMS_MASK)
+   return -EIO;
+
+   /* return valid GMS value, -EIO if invalid */
+   gms = REG_FIELD_GET(GMS_MASK, ggc);
+   switch (gms) {
+   case 0x0 ... 0x04:
+   return gms * 32;
+   case 0xf0 ... 0xfe:
+   return (gms - 0xf0 + 1) * 4;
+   default:
+   MISSING_CASE(gms);
+   return -EIO;
+   }
+}
+
 struct intel_memory_region *
 i915_gem_stolen_lmem_setup(struct drm_i

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Remove PLL asserts from .load_luts()

[Jani Nikula]

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> .load_luts() potentially runs from the vblank worker, and is
> under a deadline to complete within the vblank. Thus we can't
> do expesive stuff like talk to the Punit, etc.
>
> To that end get rid of the assert_dsi_pll_enabled() call for
> vlv/chv. We'll just have to trust that the PLL is already enabled
> here.
>
> And I don't think the normal assert_pll_enabled() really buys us
> anything useful on gmch platforms either, so nuke that one too.
> We don't have corresponding asserts in the ilk+ codepaths anyway
> despite the hardware (IIRC) still requiring the clock to be
> enabled when we access the LUT.
>
> Signed-off-by: Ville Syrjälä 

Acked-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 11 ---
>  1 file changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 6bda4274eae9..bbc56affb3ec 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -25,9 +25,7 @@
>  #include "intel_color.h"
>  #include "intel_de.h"
>  #include "intel_display_types.h"
> -#include "intel_dpll.h"
>  #include "intel_dsb.h"
> -#include "vlv_dsi_pll.h"
>  
>  struct intel_color_funcs {
>   int (*color_check)(struct intel_crtc_state *crtc_state);
> @@ -580,11 +578,8 @@ static void i9xx_load_lut_8(struct intel_crtc *crtc,
>  static void i9xx_load_luts(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
>  
> - assert_pll_enabled(dev_priv, crtc->pipe);
> -
>   i9xx_load_lut_8(crtc, gamma_lut);
>  }
>  
> @@ -611,14 +606,8 @@ static void i965_load_lut_10p6(struct intel_crtc *crtc,
>  static void i965_load_luts(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
>  
> - if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI))
> - assert_dsi_pll_enabled(dev_priv);
> - else
> - assert_pll_enabled(dev_priv, crtc->pipe);
> -
>   if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT)
>   i9xx_load_lut_8(crtc, gamma_lut);
>   else

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Split up intel_color_init()

[Jani Nikula]

On Thu, 29 Sep 2022, Jani Nikula  wrote:
> On Thu, 29 Sep 2022, Ville Syrjala  wrote:
>> From: Ville Syrjälä 
>>
>> intel_color_init() does both device level and crtc level stuff.
>> Split it up accordingly.
>>
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/i915/display/intel_color.c   | 15 +--
>>  drivers/gpu/drm/i915/display/intel_color.h   |  4 +++-
>>  drivers/gpu/drm/i915/display/intel_crtc.c|  3 +--
>>  drivers/gpu/drm/i915/display/intel_display.c |  1 +
>>  4 files changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
>> b/drivers/gpu/drm/i915/display/intel_color.c
>> index bbc56affb3ec..ddfe7c257a72 100644
>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>> @@ -2206,13 +2206,21 @@ static const struct intel_color_funcs 
>> ilk_color_funcs = {
>>  .read_luts = ilk_read_luts,
>>  };
>>  
>> -void intel_color_init(struct intel_crtc *crtc)
>> +void intel_crtc_color_init(struct intel_crtc *crtc)
>>  {
>>  struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>>  bool has_ctm = INTEL_INFO(dev_priv)->display.color.degamma_lut_size != 
>> 0;
>>  
>>  drm_mode_crtc_set_gamma_size(&crtc->base, 256);
>>  
>> +drm_crtc_enable_color_mgmt(&crtc->base,
>> +   
>> INTEL_INFO(dev_priv)->display.color.degamma_lut_size,
>> +   has_ctm,
>> +   
>> INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
>> +}
>> +
>> +void intel_color_init_hooks(struct drm_i915_private *dev_priv)
>> +{
>>  if (HAS_GMCH(dev_priv)) {
>>  if (IS_CHERRYVIEW(dev_priv)) {
>>  dev_priv->display.funcs.color = &chv_color_funcs;
>> @@ -2238,9 +2246,4 @@ void intel_color_init(struct intel_crtc *crtc)
>>  } else
>>  dev_priv->display.funcs.color = &ilk_color_funcs;
>>  }
>> -
>> -drm_crtc_enable_color_mgmt(&crtc->base,
>> -   
>> INTEL_INFO(dev_priv)->display.color.degamma_lut_size,
>> -   has_ctm,
>> -   
>> INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
>>  }
>> diff --git a/drivers/gpu/drm/i915/display/intel_color.h 
>> b/drivers/gpu/drm/i915/display/intel_color.h
>> index fd873425e082..67702451e2fd 100644
>> --- a/drivers/gpu/drm/i915/display/intel_color.h
>> +++ b/drivers/gpu/drm/i915/display/intel_color.h
>> @@ -10,9 +10,11 @@
>>  
>>  struct intel_crtc_state;
>>  struct intel_crtc;
>> +struct drm_i915_private;
>>  struct drm_property_blob;
>>  
>> -void intel_color_init(struct intel_crtc *crtc);
>> +void intel_color_init_hooks(struct drm_i915_private *i915);
>> +void intel_crtc_color_init(struct intel_crtc *crtc);
>>  int intel_color_check(struct intel_crtc_state *crtc_state);
>>  void intel_color_commit_noarm(const struct intel_crtc_state *crtc_state);
>>  void intel_color_commit_arm(const struct intel_crtc_state *crtc_state);
>> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
>> b/drivers/gpu/drm/i915/display/intel_crtc.c
>> index 6792a9056f46..2d9fc7383bfc 100644
>> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
>> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
>> @@ -365,8 +365,7 @@ int intel_crtc_init(struct drm_i915_private *dev_priv, 
>> enum pipe pipe)
>>  BIT(DRM_SCALING_FILTER_DEFAULT) 
>> |
>>  
>> BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
>>  
>> -intel_color_init(crtc);
>> -
>> +intel_crtc_color_init(crtc);
>>  intel_crtc_drrs_init(crtc);
>>  intel_crtc_crc_init(crtc);
>
> I'd name all of these like:
>
>   intel_color_crtc_init();
> intel_drrs_crtc_init();
> intel_crc_crtc_init();
>
> I think in gem side the "name functions based on first/context argument"
> style has lead to serious problems wrt code organization. They still
> stick to it, but I can't make heads or tails where function definitions
> or declarations are supposed to be placed or found.

The patch itself is fine, and follows the precedent set by the above
functions, but I'd *really* like to see all the above functions renamed
afterwards.

Reviewed-by: Jani Nikula 

>
> BR,
> Jani.
>
>
>>  
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index eb8eaeb19881..a103413cb081 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -8326,6 +8326,7 @@ void intel_init_display_hooks(struct drm_i915_private 
>> *dev_priv)
>>  if (!HAS_DISPLAY(dev_priv))
>>  return;
>>  
>> +intel_color_init_hooks(dev_priv);
>>  intel_init_cdclk_hooks(dev_priv);
>>  intel_audio_hooks_init(dev_priv);

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Simplify the intel_color_init_hooks() if ladder

[Jani Nikula]

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Get rid of the funny hsw vs. ivb extra indentation level in
> intel_color_init_hooks().
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index ddfe7c257a72..ce8a4be9b292 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2238,12 +2238,11 @@ void intel_color_init_hooks(struct drm_i915_private 
> *dev_priv)
>   dev_priv->display.funcs.color = &skl_color_funcs;
>   else if (DISPLAY_VER(dev_priv) == 8)
>   dev_priv->display.funcs.color = &bdw_color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 7) {
> - if (IS_HASWELL(dev_priv))
> - dev_priv->display.funcs.color = 
> &hsw_color_funcs;
> - else
> - dev_priv->display.funcs.color = 
> &ivb_color_funcs;
> - } else
> + else if (IS_HASWELL(dev_priv))
> + dev_priv->display.funcs.color = &hsw_color_funcs;
> + else if (DISPLAY_VER(dev_priv) == 7)
> + dev_priv->display.funcs.color = &ivb_color_funcs;
> + else
>   dev_priv->display.funcs.color = &ilk_color_funcs;
>   }
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Clean up intel_color_init_hooks()

[Jani Nikula]

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Remove a bunch of pointless curly brackets and do
> the s/dev_priv/i915/ while at it.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 43 +++---
>  1 file changed, 21 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index ce8a4be9b292..96687ec30b19 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -2219,30 +2219,29 @@ void intel_crtc_color_init(struct intel_crtc *crtc)
>  
> INTEL_INFO(dev_priv)->display.color.gamma_lut_size);
>  }
>  
> -void intel_color_init_hooks(struct drm_i915_private *dev_priv)
> +void intel_color_init_hooks(struct drm_i915_private *i915)
>  {
> - if (HAS_GMCH(dev_priv)) {
> - if (IS_CHERRYVIEW(dev_priv)) {
> - dev_priv->display.funcs.color = &chv_color_funcs;
> - } else if (DISPLAY_VER(dev_priv) >= 4) {
> - dev_priv->display.funcs.color = &i965_color_funcs;
> - } else {
> - dev_priv->display.funcs.color = &i9xx_color_funcs;
> - }
> + if (HAS_GMCH(i915)) {
> + if (IS_CHERRYVIEW(i915))
> + i915->display.funcs.color = &chv_color_funcs;
> + else if (DISPLAY_VER(i915) >= 4)
> + i915->display.funcs.color = &i965_color_funcs;
> + else
> + i915->display.funcs.color = &i9xx_color_funcs;
>   } else {
> - if (DISPLAY_VER(dev_priv) >= 11)
> - dev_priv->display.funcs.color = &icl_color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 10)
> - dev_priv->display.funcs.color = &glk_color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 9)
> - dev_priv->display.funcs.color = &skl_color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 8)
> - dev_priv->display.funcs.color = &bdw_color_funcs;
> - else if (IS_HASWELL(dev_priv))
> - dev_priv->display.funcs.color = &hsw_color_funcs;
> - else if (DISPLAY_VER(dev_priv) == 7)
> - dev_priv->display.funcs.color = &ivb_color_funcs;
> + if (DISPLAY_VER(i915) >= 11)
> + i915->display.funcs.color = &icl_color_funcs;
> + else if (DISPLAY_VER(i915) == 10)
> + i915->display.funcs.color = &glk_color_funcs;
> + else if (DISPLAY_VER(i915) == 9)
> + i915->display.funcs.color = &skl_color_funcs;
> + else if (DISPLAY_VER(i915) == 8)
> + i915->display.funcs.color = &bdw_color_funcs;
> + else if (IS_HASWELL(i915))
> + i915->display.funcs.color = &hsw_color_funcs;
> + else if (DISPLAY_VER(i915) == 7)
> + i915->display.funcs.color = &ivb_color_funcs;
>   else
> - dev_priv->display.funcs.color = &ilk_color_funcs;
> + i915->display.funcs.color = &ilk_color_funcs;
>   }
>  }

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Change glk_load_degamma_lut() calling convention

[Jani Nikula]

On Thu, 29 Sep 2022, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Make glk_load_degamma_lut() more like most everyone else and
> pass in the LUT explicitly.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 96687ec30b19..0c73b2ba1283 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -826,13 +826,14 @@ static int glk_degamma_lut_size(struct drm_i915_private 
> *i915)
>   return 35;
>  }
>  
> -static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state)
> +static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state,
> +  const struct drm_property_blob *blob)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + const struct drm_color_lut *lut = blob->data;
> + int i, lut_size = drm_color_lut_size(blob);
>   enum pipe pipe = crtc->pipe;
> - int i, lut_size = INTEL_INFO(dev_priv)->display.color.degamma_lut_size;
> - const struct drm_color_lut *lut = crtc_state->hw.degamma_lut->data;
>  
>   /*
>* When setting the auto-increment bit, the hardware seems to
> @@ -899,6 +900,7 @@ static void glk_load_degamma_lut_linear(const struct 
> intel_crtc_state *crtc_stat
>  
>  static void glk_load_luts(const struct intel_crtc_state *crtc_state)
>  {
> + const struct drm_property_blob *degamma_lut = 
> crtc_state->hw.degamma_lut;
>   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
> @@ -910,8 +912,8 @@ static void glk_load_luts(const struct intel_crtc_state 
> *crtc_state)
>* the degama LUT so that we don't have to reload
>* it every time the pipe CSC is being enabled.
>*/
> - if (crtc_state->hw.degamma_lut)
> - glk_load_degamma_lut(crtc_state);
> + if (degamma_lut)
> + glk_load_degamma_lut(crtc_state, degamma_lut);
>   else
>   glk_load_degamma_lut_linear(crtc_state);
>  
> @@ -1043,11 +1045,12 @@ icl_program_gamma_multi_segment(const struct 
> intel_crtc_state *crtc_state)
>  
>  static void icl_load_luts(const struct intel_crtc_state *crtc_state)
>  {
> + const struct drm_property_blob *degamma_lut = 
> crtc_state->hw.degamma_lut;
>   const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
> - if (crtc_state->hw.degamma_lut)
> - glk_load_degamma_lut(crtc_state);
> + if (degamma_lut)
> + glk_load_degamma_lut(crtc_state, degamma_lut);
>  
>   switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
>   case GAMMA_MODE_MODE_8BIT:

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: enable local stolen memory (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: enable local stolen memory (rev4)
URL   : https://patchwork.freedesktop.org/series/109066/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109066v4_full


Summary
---

  **FAILURE**

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

  

Participating hosts (10 -> 12)
--

  Additional (2): shard-dg1 shard-tglu 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@drm_fdinfo@virtual-busy-hang-all:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12193/shard-tglb7/igt@drm_fdi...@virtual-busy-hang-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v4/shard-tglb8/igt@drm_fdi...@virtual-busy-hang-all.html

  * {igt@gem_mmap_offset@ptrace@lmem0-fixed} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109066v4/shard-dg1-12/igt@gem_mmap_offset@ptr...@lmem0-fixed.html

  
New tests
-

  New tests have been introduced between CI_DRM_12193_full and 
Patchwork_109066v4_full:

### New IGT tests (39) ###

  * igt@gem_mmap_offset@ptrace@lmem0-fixed:
- Statuses : 1 fail(s)
- Exec time: [0.02] s

  * igt@gem_mmap_offset@ptrace@smem0-fixed:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_color@ctm-0-50@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [1.17] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.39] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.23] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.24] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@cursor_implicit_plane@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.31] s

  * igt@kms_lease@cursor_implicit_plane@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@cursor_implicit_plane@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@cursor_implicit_plane@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@empty_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@empty_lease@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lease_invalid_connector@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_connector@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_revoke@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_lease@lease_revoke@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-4:

[Intel-gfx] Information about XDC 2022 - next week!

[Jeremy White]

Hi folks,

We are excited to welcome you in person to the 2022 X.Org Developers 
Conference, held in conjunction with WineConf and FOSS XR conference.


The conference will start officially on Tuesday morning, October 4th. 
The program is here:

  https://indico.freedesktop.org/event/2/timetable/#all.detailed
The official events start at 8:30 am, but we will have coffee and 
pastries available from 7:30 on Tuesday and 8 on Wednesday and Thursday.


We expect everyone attending to be vaccinated and to be respectful of 
people that are trying to avoid catching COVID. Masks are mandatory, 
except when presenting or eating.


A small number of us will gather informally at Brit’s Pub, starting at 
around 4:00 pm on Monday, October 3rd.  We’ll try to have a table with 
some sort of a sign, and folks can connect, have a drink, and then 
perhaps group up to explore alternate food.  Note that if the weather is 
nice, we may be up on the roof, so explore far to find us.


We will be on the Minneapolis campus of St. Thomas, which is a mildly 
confusing campus.  We have given instructions and a picture to guide you 
here:


https://indico.freedesktop.org/event/2/page/10-attending-xdc-wineconf-foss-xr
We are working on the remote experience, and expect to have streaming of 
all events available. The above page will have those details just as 
soon as they are finalized.


We have a page of instructions for folks that will be presenting:
  https://indico.freedesktop.org/event/2/page/18-speaker-instructions

We are also excited to announce the happy hour taking place on 
Wednesday, from 6:00 pm until 8:00 pm.  The hope is that all three 
projects can mingle and socialize and enjoy the return of in person 
meetings.


Also, this year we plan to adopt the Wine strategy of using a deliberate 
Matrix chat room just for the conference.  Matrix has a variety of apps, 
and Element, the default one is easy to configure on many devices, 
including mobile phones.  The link to that channel is here:

  https://matrix.to/#/#xdc-wineconf-fossxr-2022:matrix.org
We find the chat channel a good place to learn what restaurants and bars 
are chosen, and just a good way to track the social aspects of the 
conference.


We look forward to seeing you next week!

Cheers,

Jeremy

[Intel-gfx] [PATCH] drm/i915/gvt: fix double free bug in split_2MB_gtt_entry

[Zheng Wang]

If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt.
But the caller does not notice that, it will free spt again in error path.

Fix this by only freeing spt in ppgtt_invalidate_spt in good case.

Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
Reported-by: Zheng Wang 
Signed-off-by: Zheng Wang 
---
 drivers/gpu/drm/i915/gvt/gtt.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index ce0eb03709c3..550519f0acca 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -959,7 +959,7 @@ static inline int ppgtt_put_spt(struct intel_vgpu_ppgtt_spt 
*spt)
return atomic_dec_return(&spt->refcount);
 }
 
-static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt);
+static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt, int 
is_error);
 
 static int ppgtt_invalidate_spt_by_shadow_entry(struct intel_vgpu *vgpu,
struct intel_gvt_gtt_entry *e)
@@ -995,7 +995,7 @@ static int ppgtt_invalidate_spt_by_shadow_entry(struct 
intel_vgpu *vgpu,
ops->get_pfn(e));
return -ENXIO;
}
-   return ppgtt_invalidate_spt(s);
+   return ppgtt_invalidate_spt(s, 0);
 }
 
 static inline void ppgtt_invalidate_pte(struct intel_vgpu_ppgtt_spt *spt,
@@ -1016,7 +1016,7 @@ static inline void ppgtt_invalidate_pte(struct 
intel_vgpu_ppgtt_spt *spt,
intel_gvt_dma_unmap_guest_page(vgpu, pfn << PAGE_SHIFT);
 }
 
-static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt)
+static int ppgtt_invalidate_spt(struct intel_vgpu_ppgtt_spt *spt, int is_error)
 {
struct intel_vgpu *vgpu = spt->vgpu;
struct intel_gvt_gtt_entry e;
@@ -1059,9 +1059,11 @@ static int ppgtt_invalidate_spt(struct 
intel_vgpu_ppgtt_spt *spt)
}
}
 
-   trace_spt_change(spt->vgpu->id, "release", spt,
+   if (!is_error) {
+   trace_spt_change(spt->vgpu->id, "release", spt,
 spt->guest_page.gfn, spt->shadow_page.type);
-   ppgtt_free_spt(spt);
+   ppgtt_free_spt(spt);
+   }
return 0;
 fail:
gvt_vgpu_err("fail: shadow page %p shadow entry 0x%llx type %d\n",
@@ -1215,7 +1217,7 @@ static int split_2MB_gtt_entry(struct intel_vgpu *vgpu,
ret = intel_gvt_dma_map_guest_page(vgpu, start_gfn + sub_index,
   PAGE_SIZE, &dma_addr);
if (ret) {
-   ppgtt_invalidate_spt(spt);
+   ppgtt_invalidate_spt(spt, 1);
return ret;
}
sub_se.val64 = se->val64;
@@ -1393,7 +1395,7 @@ static int ppgtt_handle_guest_entry_removal(struct 
intel_vgpu_ppgtt_spt *spt,
ret = -ENXIO;
goto fail;
}
-   ret = ppgtt_invalidate_spt(s);
+   ret = ppgtt_invalidate_spt(s, 0);
if (ret)
goto fail;
} else {
-- 
2.25.1

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Fix PSR_IMR/IIR field handling

[Souza, Jose]

On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
> 
> /*
>  * gen12+ has registers relative to transcoder and one per transcoder
>  * using the same bit definition: handle it as TRANSCODER_EDP to force
>  * 0 shift in bit definition
>  */
> 
> At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
> This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
> incorrectly if DISPLAY_VER >= 12.
> 
> Fix this by adding separate register field defines for >=12 and add bit
> getter functions to keep code readability.
> 
> v3:
>  - Add separate register field defines (José)
>  - Add bit getter functions (José)
> v2:
>  - Improve commit message (José)
> 
> Signed-off-by: Jouni Högander 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 84 ++--
>  drivers/gpu/drm/i915/i915_reg.h  | 16 +++--
>  2 files changed, 62 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9def8d9fade6..d7b08a7da9e9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -116,34 +116,56 @@ static bool psr2_global_enabled(struct intel_dp 
> *intel_dp)
>   }
>  }
>  
> +static u32 psr_irq_psr_error_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_ERROR :
> + EDP_PSR_ERROR(intel_dp->psr.transcoder);

Drop the "_EDP", just go with TGL_PSR_ERROR... there is no reference to EDP or 
any transcoder in TGL+ it is one register per transcoder.

> +}
> +
> +static u32 psr_irq_post_exit_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_POST_EXIT :
> + EDP_PSR_POST_EXIT(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_pre_entry_bit_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_PRE_ENTRY :
> + EDP_PSR_PRE_ENTRY(intel_dp->psr.transcoder);
> +}
> +
> +static u32 psr_irq_mask_get(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_MASK :
> + EDP_PSR_MASK(intel_dp->psr.transcoder);
> +}
> +
>  static void psr_irq_control(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> - enum transcoder trans_shift;
>   i915_reg_t imr_reg;
>   u32 mask, val;
>  
> - /*
> -  * gen12+ has registers relative to transcoder and one per transcoder
> -  * using the same bit definition: handle it as TRANSCODER_EDP to force
> -  * 0 shift in bit definition
> -  */
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + if (DISPLAY_VER(dev_priv) >= 12)
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> - } else {
> - trans_shift = intel_dp->psr.transcoder;
> + else
>   imr_reg = EDP_PSR_IMR;
> - }
>  
> - mask = EDP_PSR_ERROR(trans_shift);
> + mask = psr_irq_psr_error_bit_get(intel_dp);
>   if (intel_dp->psr.debug & I915_PSR_DEBUG_IRQ)
> - mask |= EDP_PSR_POST_EXIT(trans_shift) |
> - EDP_PSR_PRE_ENTRY(trans_shift);
> + mask |= psr_irq_post_exit_bit_get(intel_dp) |
> + psr_irq_pre_entry_bit_get(intel_dp);
>  
> - /* Warning: it is masking/setting reserved bits too */
>   val = intel_de_read(dev_priv, imr_reg);
> - val &= ~EDP_PSR_TRANS_MASK(trans_shift);
> + val &= ~psr_irq_mask_get(intel_dp);
>   val |= ~mask;
>   intel_de_write(dev_priv, imr_reg, val);
>  }
> @@ -191,25 +213,21 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, 
> u32 psr_iir)
>   enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   ktime_t time_ns =  ktime_get();
> - enum transcoder trans_shift;
>   i915_reg_t imr_reg;
>  
> - if (DISPLAY_VER(dev_priv) >= 12) {
> - trans_shift = 0;
> + if (DISPLAY_VER(dev_priv) >= 12)
>   imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> - } else {
> - trans_shift = intel_dp->psr.transcoder;
> + else
>   imr_reg = EDP_PSR_IMR;
> - }
>  
> - if (psr_iir & EDP_PSR_PRE_ENTRY(trans_shift)) {
> + if (psr_iir & psr_irq_pre_entry_bit_get(intel_dp)) {
>   intel_dp->psr.last_entry_attempt = time_ns;
>   drm_dbg_kms(&dev_priv->drm,
>   "[transcoder %s] PSR entry attempt in 2 vblanks\n"

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Fix PSR_IMR/IIR field handling

[Souza, Jose]

On Thu, 2022-09-29 at 06:16 -0700, José Roberto de Souza wrote:
> On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> > bits in PSR_IMR/IIR registers:
> > 
> > /*
> >  * gen12+ has registers relative to transcoder and one per transcoder
> >  * using the same bit definition: handle it as TRANSCODER_EDP to force
> >  * 0 shift in bit definition
> >  */
> > 
> > At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
> > This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
> > incorrectly if DISPLAY_VER >= 12.
> > 
> > Fix this by adding separate register field defines for >=12 and add bit
> > getter functions to keep code readability.
> > 
> > v3:
> >  - Add separate register field defines (José)
> >  - Add bit getter functions (José)
> > v2:
> >  - Improve commit message (José)

Also missing the Fixes tag, so this gets backported to stable kernels.

> > 
> > Signed-off-by: Jouni Högander 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 84 ++--
> >  drivers/gpu/drm/i915/i915_reg.h  | 16 +++--
> >  2 files changed, 62 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 9def8d9fade6..d7b08a7da9e9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -116,34 +116,56 @@ static bool psr2_global_enabled(struct intel_dp 
> > *intel_dp)
> > }
> >  }
> >  
> > +static u32 psr_irq_psr_error_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_ERROR :
> > +   EDP_PSR_ERROR(intel_dp->psr.transcoder);
> 
> Drop the "_EDP", just go with TGL_PSR_ERROR... there is no reference to EDP 
> or any transcoder in TGL+ it is one register per transcoder.
> 
> > +}
> > +
> > +static u32 psr_irq_post_exit_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_POST_EXIT :
> > +   EDP_PSR_POST_EXIT(intel_dp->psr.transcoder);
> > +}
> > +
> > +static u32 psr_irq_pre_entry_bit_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_PRE_ENTRY :
> > +   EDP_PSR_PRE_ENTRY(intel_dp->psr.transcoder);
> > +}
> > +
> > +static u32 psr_irq_mask_get(struct intel_dp *intel_dp)
> > +{
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > +   return DISPLAY_VER(dev_priv) >= 12 ? TGL_EDP_PSR_MASK :
> > +   EDP_PSR_MASK(intel_dp->psr.transcoder);
> > +}
> > +
> >  static void psr_irq_control(struct intel_dp *intel_dp)
> >  {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > -   enum transcoder trans_shift;
> > i915_reg_t imr_reg;
> > u32 mask, val;
> >  
> > -   /*
> > -* gen12+ has registers relative to transcoder and one per transcoder
> > -* using the same bit definition: handle it as TRANSCODER_EDP to force
> > -* 0 shift in bit definition
> > -*/
> > -   if (DISPLAY_VER(dev_priv) >= 12) {
> > -   trans_shift = 0;
> > +   if (DISPLAY_VER(dev_priv) >= 12)
> > imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> > -   } else {
> > -   trans_shift = intel_dp->psr.transcoder;
> > +   else
> > imr_reg = EDP_PSR_IMR;
> > -   }
> >  
> > -   mask = EDP_PSR_ERROR(trans_shift);
> > +   mask = psr_irq_psr_error_bit_get(intel_dp);
> > if (intel_dp->psr.debug & I915_PSR_DEBUG_IRQ)
> > -   mask |= EDP_PSR_POST_EXIT(trans_shift) |
> > -   EDP_PSR_PRE_ENTRY(trans_shift);
> > +   mask |= psr_irq_post_exit_bit_get(intel_dp) |
> > +   psr_irq_pre_entry_bit_get(intel_dp);
> >  
> > -   /* Warning: it is masking/setting reserved bits too */
> > val = intel_de_read(dev_priv, imr_reg);
> > -   val &= ~EDP_PSR_TRANS_MASK(trans_shift);
> > +   val &= ~psr_irq_mask_get(intel_dp);
> > val |= ~mask;
> > intel_de_write(dev_priv, imr_reg, val);
> >  }
> > @@ -191,25 +213,21 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, 
> > u32 psr_iir)
> > enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > ktime_t time_ns =  ktime_get();
> > -   enum transcoder trans_shift;
> > i915_reg_t imr_reg;
> >  
> > -   if (DISPLAY_VER(dev_priv) >= 12) {
> > -   trans_shift = 0;
> > +   if (DISPLAY_VER(dev_priv) >= 12)
> > imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> > -   } else {
> > -   trans_shift = intel_dp->psr.transcoder;
> > +   else
> > imr_reg = EDP_PSR_IMR;
> > -   }
> >  
> > -   if (psr_ii

[Intel-gfx] [PATCH 0/5] drm/i915/mtl: Add C10 phy support

[Mika Kahola]

PHY programming support for message bus and phy programming.
Updates for HDMI programming and vswing tables.

Radhakrishna Sripada (5):
  drm/i915/mtl: Add Support for C10,C20 PHY Message Bus
  drm/i915/mtl: Add PLL programming support for C10 phy
  drm/i915/mtl: Add support for C10 phy programming
  drm/i915/mtl: Add C10 phy programming for HDMI
  drm/i915/mtl: Add vswing programming for C10 phys

 drivers/gpu/drm/i915/Makefile |1 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 1300 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |  155 ++
 drivers/gpu/drm/i915/display/intel_ddi.c  |   26 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|   36 +-
 .../drm/i915/display/intel_ddi_buf_trans.h|6 +
 drivers/gpu/drm/i915/display/intel_display.c  |1 +
 .../drm/i915/display/intel_display_power.c|3 +-
 .../i915/display/intel_display_power_map.c|1 +
 .../i915/display/intel_display_power_well.c   |2 +-
 .../drm/i915/display/intel_display_types.h|6 +
 drivers/gpu/drm/i915/display/intel_dp.c   |   15 +-
 drivers/gpu/drm/i915/display/intel_dpll.c |   22 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |5 +-
 .../drm/i915/display/intel_modeset_verify.c   |2 +
 drivers/gpu/drm/i915/i915_reg.h   |  142 ++
 17 files changed, 1716 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h

-- 
2.34.1

[Intel-gfx] [PATCH 2/5] drm/i915/mtl: Add PLL programming support for C10 phy

[Mika Kahola]

From: Radhakrishna Sripada 

XELPDP has C10 phys to drive output to the EDP and the native output
from the display engine. Add structures, programming hardware state
readout logic. Port clock calculations are similar to DG2. Use the DG2
formulae to calculate the port clock but use the relevant pll signals.
Note: PHY lane 0 is always used for PLL programming.

Bspec: 64568, 64539, 67636

Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 516 +-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  | 128 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |  20 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   1 +
 .../drm/i915/display/intel_display_power.c|   3 +-
 .../i915/display/intel_display_power_well.c   |   2 +-
 .../drm/i915/display/intel_display_types.h|   6 +
 drivers/gpu/drm/i915/display/intel_dpll.c |  20 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |   2 +-
 .../drm/i915/display/intel_modeset_verify.c   |   2 +
 10 files changed, 690 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 7930b0255cfa..2f401116d1d0 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -3,7 +3,11 @@
  * Copyright © 2021 Intel Corporation
  */
 
+#include "intel_cx0_phy.h"
 #include "intel_de.h"
+#include "intel_display_types.h"
+#include "intel_dp.h"
+#include "intel_panel.h"
 #include "intel_uncore.h"
 
 static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
@@ -26,7 +30,7 @@ static void intel_cx0_bus_reset(struct drm_i915_private 
*i915, enum port port, i
return;
 }
 
-__maybe_unused static u8 intel_cx0_read(struct drm_i915_private *i915, enum 
port port,
+static u8 intel_cx0_read(struct drm_i915_private *i915, enum port port,
 int lane, u16 addr)
 {
enum phy phy = intel_port_to_phy(i915, port);
@@ -116,8 +120,8 @@ static int intel_cx0_wait_cwrite_ack(struct 
drm_i915_private *i915,
return 0;
 }
 
-__maybe_unused static void intel_cx0_write(struct drm_i915_private *i915, enum 
port port,
-   int lane, u16 addr, u8 data, bool committed)
+static void __intel_cx0_write(struct drm_i915_private *i915, enum port port,
+ int lane, u16 addr, u8 data, bool committed)
 {
enum phy phy = intel_port_to_phy(i915, port);
int attempts = 0;
@@ -166,8 +170,19 @@ __maybe_unused static void intel_cx0_write(struct 
drm_i915_private *i915, enum p
return;
 }
 
-__maybe_unused static void intel_cx0_rmw(struct drm_i915_private *i915, enum 
port port,
- int lane, u16 addr, u8 clear, u8 set, bool committed)
+static void intel_cx0_write(struct drm_i915_private *i915, enum port port,
+   int lane, u16 addr, u8 data, bool committed)
+{
+   if (lane == INTEL_CX0_BOTH_LANES) {
+   __intel_cx0_write(i915, port, INTEL_CX0_LANE0, addr, data, 
committed);
+   __intel_cx0_write(i915, port, INTEL_CX0_LANE1, addr, data, 
committed);
+   } else {
+   __intel_cx0_write(i915, port, lane, addr, data, committed);
+   }
+}
+
+static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
+   int lane, u16 addr, u8 clear, u8 set, bool 
committed)
 {
u8 old, val;
 
@@ -177,3 +192,494 @@ __maybe_unused static void intel_cx0_rmw(struct 
drm_i915_private *i915, enum por
if (val != old)
intel_cx0_write(i915, port, lane, addr, val, committed);
 }
+
+static void intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
+ int lane, u16 addr, u8 clear, u8 set, bool committed)
+{
+   if (lane == INTEL_CX0_BOTH_LANES) {
+   __intel_cx0_rmw(i915, port, INTEL_CX0_LANE0, addr, clear, set, 
committed);
+   __intel_cx0_rmw(i915, port, INTEL_CX0_LANE1, addr, clear, set, 
committed);
+   } else {
+   __intel_cx0_rmw(i915, port, lane, addr, clear, set, committed);
+   }
+}
+
+/*
+ * Basic DP link rates with 38.4 MHz reference clock.
+ * Note: The tables below are with SSC. In non-ssc
+ * registers 0xC04 to 0xC08(pll[4] to pll[8]) will be
+ * programmed 0.
+ */
+
+static const struct intel_c10mpllb_state mtl_c10_dp_rbr = {
+   .clock = 162000,
+   .pll[0] = 0xB4,
+   .pll[1] = 0,
+   .pll[2] = 0x30,
+   .pll[3] = 0x1,
+   .pll[4] = 0x26,
+   .pll[5] = 0x0C,
+   .pll[6] = 0x98,
+   .pll[7] = 0x46,
+   .pll[8] = 0x1,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0xC0,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0x2,
+   .pll[16] = 0x84,
+   .pll[17] = 0x4F,

[Intel-gfx] [PATCH 3/5] drm/i915/mtl: Add support for C10 phy programming

[Mika Kahola]

From: Radhakrishna Sripada 

Add sequences for C10 phy enable/disable phy lane reset,
powerdown change sequence and phy lane programming.

Bspec: 64539, 67636, 65451, 65450, 64568

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola  (v9)
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 352 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |  17 +
 drivers/gpu/drm/i915/display/intel_ddi.c |   2 +
 drivers/gpu/drm/i915/display/intel_dp.c  |  15 +-
 drivers/gpu/drm/i915/display/intel_dpll.c|   2 +
 drivers/gpu/drm/i915/i915_reg.h  | 141 
 7 files changed, 526 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..994f87a12782 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -279,6 +279,7 @@ i915-y += \
display/icl_dsi.o \
display/intel_backlight.o \
display/intel_crt.o \
+   display/intel_cx0_phy.o \
display/intel_ddi.o \
display/intel_ddi_buf_trans.o \
display/intel_display_trace.o \
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 2f401116d1d0..6ba11cd7cd75 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -526,9 +526,9 @@ void intel_c10mpllb_readout_hw_state(struct intel_encoder 
*encoder,
 tx0, cmn, phy_name(phy));
 }
 
-__maybe_unused static void intel_c10_pll_program(struct drm_i915_private *i915,
-const struct intel_crtc_state 
*crtc_state,
-struct intel_encoder *encoder)
+static void intel_c10_pll_program(struct drm_i915_private *i915,
+ const struct intel_crtc_state *crtc_state,
+ struct intel_encoder *encoder)
 {
const struct intel_c10mpllb_state *pll_state = 
&crtc_state->c10mpllb_state;
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
@@ -633,6 +633,352 @@ int intel_c10mpllb_calc_port_clock(struct intel_encoder 
*encoder,
 10 << (tx_clk_div + 16));
 }
 
+#define PHY_LANES_VAL_ARG(FIELD, lanes, arg)   ({u32 __val; switch(lanes) {\
+ case INTEL_CX0_BOTH_LANES:
\
+   __val = 
((XELPDP_LANE0_##FIELD(arg)) |\
+   
(XELPDP_LANE1_##FIELD(arg))); \
+   break;  
\
+ case INTEL_CX0_LANE0: 
\
+   __val = 
(XELPDP_LANE0_##FIELD(arg));\
+   break;  
\
+ case INTEL_CX0_LANE1: 
\
+   __val = 
(XELPDP_LANE1_##FIELD(arg));\
+   break;  \
+}; __val; })
+
+#define PHY_LANES_VAL(FIELD, lanes)({u32 __val; switch(lanes) {\
+ case INTEL_CX0_BOTH_LANES:
\
+   __val = 
(XELPDP_LANE0_##FIELD | \
+   
XELPDP_LANE1_##FIELD); \
+   break;  
\
+ case INTEL_CX0_LANE0: 
\
+   __val = 
(XELPDP_LANE0_##FIELD);  \
+   break;  
\
+ case INTEL_CX0_LANE1: 
\
+   __val = 
(XELPDP_LANE1_##FIELD);\
+   break;  \
+}; __val; })
+
+static void intel_program_port_clock_ctl(struct intel_encoder *encoder,
+const struct intel_crtc_state 
*crtc_state,
+bool lane_reversal)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp;
+   bool ssc_enabled;
+   u32 val = 0;
+
+   intel_de_rmw(i915, XELPDP_PORT_BUF_CTL1(encoder->port), 
XELPDP_PORT_REVERSAL,
+lane_reversal ? XELPDP_PORT_REVERSAL : 0);
+
+   if (lane_reversal)
+   val |= XELPDP_LANE

[Intel-gfx] [PATCH 4/5] drm/i915/mtl: Add C10 phy programming for HDMI

[Mika Kahola]

From: Radhakrishna Sripada 

Like DG2, we still don't have a proper algorithm that can be used
for calculating PHY settings, but we do have tables of register
values for a handful of the more common link rates. Some support is
better than none, so let's go ahead and add/use these tables when we
can, and also add some logic to hdmi_port_clock_valid() to filter the
modelist to just the modes we can actually support with these link
rates.

Hopefully we'll have a proper / non-encumbered algorithm to calculate
these registers by the time we upstream and we'll be able to replace
this patch with something more general purpose.

Bspec: 64568

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 168 ++-
 drivers/gpu/drm/i915/display/intel_cx0_phy.h |   2 +
 drivers/gpu/drm/i915/display/intel_hdmi.c|   5 +-
 3 files changed, 170 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index 6ba11cd7cd75..a08788d2a3bc 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -448,6 +448,152 @@ static const struct intel_c10mpllb_state * const 
mtl_c10_edp_tables[] = {
NULL,
 };
 
+/*
+ * HDMI link rates with 38.4 MHz reference clock.
+ */
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_25_175 = {
+   .clock = 25175,
+   .pll[0] = 0x4,
+   .pll[1] = 0,
+   .pll[2] = 0xB2,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xD,
+   .pll[16] = 0x6,
+   .pll[17] = 0x8F,
+   .pll[18] = 0x84,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_27_0 = {
+   .clock = 27000,
+   .pll[0] = 0x34,
+   .pll[1] = 0,
+   .pll[2] = 0xC0,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x80,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xD,
+   .pll[16] = 0x6,
+   .pll[17] = 0xCF,
+   .pll[18] = 0x84,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_74_25 = {
+   .clock = 74250,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xB,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_148_5 = {
+   .clock = 148500,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0xA,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state mtl_c10_hdmi_594 = {
+   .clock = 594000,
+   .pll[0] = 0xF4,
+   .pll[1] = 0,
+   .pll[2] = 0x7A,
+   .pll[3] = 0,
+   .pll[4] = 0,
+   .pll[5] = 0,
+   .pll[6] = 0,
+   .pll[7] = 0,
+   .pll[8] = 0x20,
+   .pll[9] = 0x1,
+   .pll[10] = 0,
+   .pll[11] = 0,
+   .pll[12] = 0x58,
+   .pll[13] = 0,
+   .pll[14] = 0,
+   .pll[15] = 0x8,
+   .pll[16] = 0x6,
+   .pll[17] = 0xF,
+   .pll[18] = 0x85,
+   .pll[19] = 0x23,
+};
+
+static const struct intel_c10mpllb_state * const mtl_c10_hdmi_tables[] = {
+   &mtl_c10_hdmi_25_175,
+   &mtl_c10_hdmi_27_0,
+   &mtl_c10_hdmi_74_25,
+   &mtl_c10_hdmi_148_5,
+   &mtl_c10_hdmi_594,
+   NULL,
+};
+
+int intel_c10_phy_check_hdmi_link_rate(int clock)
+{
+   const struct intel_c10mpllb_state * const *tables = mtl_c10_hdmi_tables;
+   int i;
+
+   for (i = 0; tables[i]; i++) {
+   if (clock == tables[i]->clock)
+   return MODE_OK;
+   }
+
+   return MODE_CLOCK_RANGE;
+}
+
 static const struct intel_c10mpllb_state * const *
 intel_c10_mpllb_tables_get(struct intel_crtc_state *crtc_state,
   struct intel_encoder *encoder)
@@ -457,9 +603,10 @@ intel_c10_mpllb_tables_get(struct intel_crtc_state 
*crtc_state,
r

[Intel-gfx] [PATCH 1/5] drm/i915/mtl: Add Support for C10, C20 PHY Message Bus

[Mika Kahola]

From: Radhakrishna Sripada 

XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
has a dedicated PIPE 5.2 Message bus for configuration. This message
bus is used to configure the phy internal registers.

Bspec: 64599, 65100, 65101, 67610, 67636

Cc: Mika Kahola 
Cc: Imre Deak 
Cc: Uma Shankar 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Mika Kahola  (v4)
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c | 179 +++
 1 file changed, 179 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
new file mode 100644
index ..7930b0255cfa
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include "intel_de.h"
+#include "intel_uncore.h"
+
+static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+
+   /* Bring the phy to idle. */
+   intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane),
+  XELPDP_PORT_M2P_TRANSACTION_RESET);
+
+   /* Wait for Idle Clear. */
+   if (intel_de_wait_for_clear(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, 
lane),
+   XELPDP_PORT_M2P_TRANSACTION_RESET,
+   XELPDP_MSGBUS_TIMEOUT_SLOW)) {
+   drm_err_once(&i915->drm, "Failed to bring PHY %c to idle. \n", 
phy_name(phy));
+   return;
+   }
+
+   intel_de_write(i915, XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane), ~0);
+   return;
+}
+
+__maybe_unused static u8 intel_cx0_read(struct drm_i915_private *i915, enum 
port port,
+int lane, u16 addr)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+   u32 val = 0;
+   int attempts = 0;
+
+retry:
+   if (attempts == 3) {
+   drm_err_once(&i915->drm, "PHY %c Read %04x failed after %d 
retries. Status: 0x%x\n", phy_name(phy), addr, attempts, val ?: 0);
+   return 0;
+   }
+
+   /* Wait for pending transactions.*/
+   if (intel_de_wait_for_clear(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, 
lane),
+   XELPDP_PORT_M2P_TRANSACTION_PENDING,
+   XELPDP_MSGBUS_TIMEOUT_SLOW)) {
+   drm_dbg(&i915->drm, "PHY %c Timeout waiting for previous 
transaction to complete. Reset the bus and retry.\n", phy_name(phy));
+   attempts++;
+   intel_cx0_bus_reset(i915, port, lane);
+   goto retry;
+   }
+
+   /* Issue the read command. */
+   intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane),
+  XELPDP_PORT_M2P_TRANSACTION_PENDING |
+  XELPDP_PORT_M2P_COMMAND_READ |
+  XELPDP_PORT_M2P_ADDRESS(addr));
+
+   /* Wait for response ready. And read response.*/
+   if (__intel_wait_for_register(&i915->uncore,
+ XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane),
+ XELPDP_PORT_P2M_RESPONSE_READY,
+ XELPDP_PORT_P2M_RESPONSE_READY,
+ XELPDP_MSGBUS_TIMEOUT_FAST_US,
+ XELPDP_MSGBUS_TIMEOUT_SLOW, &val)) {
+   drm_dbg(&i915->drm, "PHY %c Timeout waiting for Read response 
ACK. Status: 0x%x\n", phy_name(phy), val);
+   attempts++;
+   intel_cx0_bus_reset(i915, port, lane);
+   goto retry;
+   }
+
+   /* Check for error. */
+   if (val & XELPDP_PORT_P2M_ERROR_SET) {
+   drm_dbg(&i915->drm, "PHY %c Error occurred during read command. 
Status: 0x%x\n", phy_name(phy), val);
+   attempts++;
+   intel_cx0_bus_reset(i915, port, lane);
+   goto retry;
+   }
+
+   /* Check for Read Ack. */
+   if (REG_FIELD_GET(XELPDP_PORT_P2M_COMMAND_TYPE_MASK, val) !=
+   XELPDP_PORT_P2M_COMMAND_READ_ACK) {
+   drm_dbg(&i915->drm, "PHY %c Not a Read response. MSGBUS Status: 
0x%x.\n", phy_name(phy), val);
+   attempts++;
+   intel_cx0_bus_reset(i915, port, lane);
+   goto retry;
+   }
+
+   /* Clear Response Ready flag.*/
+   intel_de_write(i915, XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane), ~0);
+   return (u8)REG_FIELD_GET(XELPDP_PORT_P2M_DATA_MASK, val);
+}
+
+static int intel_cx0_wait_cwrite_ack(struct drm_i915_private *i915,
+ enum port port, int lane)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+   u32 val;
+
+   /* Check for write ack. */
+   if (__intel_wait_for_register(&i915->uncore,
+ XELPDP_PORT_P2M_MSGBUS_STATUS(port, l

[Intel-gfx] [PATCH 5/5] drm/i915/mtl: Add vswing programming for C10 phys

[Mika Kahola]

From: Radhakrishna Sripada 

C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
Program the levels directly to the fields in the VDR Registers.

Bspec: 65449

Cc: Imre Deak 
Cc: Mika Kahola 
Cc: Uma Shankar 
Signed-off-by: Clint Taylor 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 157 +++---
 drivers/gpu/drm/i915/display/intel_cx0_phy.h  |   8 +
 drivers/gpu/drm/i915/display/intel_ddi.c  |   4 +-
 .../drm/i915/display/intel_ddi_buf_trans.c|  36 +++-
 .../drm/i915/display/intel_ddi_buf_trans.h|   6 +
 .../i915/display/intel_display_power_map.c|   1 +
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 7 files changed, 187 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c 
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index a08788d2a3bc..bba3c4579cfa 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -4,12 +4,24 @@
  */
 
 #include "intel_cx0_phy.h"
+#include "intel_ddi.h"
+#include "intel_ddi_buf_trans.h"
 #include "intel_de.h"
 #include "intel_display_types.h"
 #include "intel_dp.h"
 #include "intel_panel.h"
+#include "intel_psr.h"
 #include "intel_uncore.h"
 
+static void
+assert_dc_off(struct drm_i915_private *i915)
+{
+   bool enabled;
+
+   enabled = intel_display_power_is_enabled(i915, POWER_DOMAIN_DC_OFF);
+   drm_WARN_ON(&i915->drm, !enabled);
+}
+
 static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, 
int lane)
 {
enum phy phy = intel_port_to_phy(i915, port);
@@ -37,6 +49,8 @@ static u8 intel_cx0_read(struct drm_i915_private *i915, enum 
port port,
u32 val = 0;
int attempts = 0;
 
+   assert_dc_off(i915);
+
 retry:
if (attempts == 3) {
drm_err_once(&i915->drm, "PHY %c Read %04x failed after %d 
retries. Status: 0x%x\n", phy_name(phy), addr, attempts, val ?: 0);
@@ -126,6 +140,8 @@ static void __intel_cx0_write(struct drm_i915_private 
*i915, enum port port,
enum phy phy = intel_port_to_phy(i915, port);
int attempts = 0;
 
+   assert_dc_off(i915);
+
 retry:
if (attempts == 3) {
drm_err_once(&i915->drm, "PHY %c Write %04x failed after %d 
retries.\n", phy_name(phy), addr, attempts);
@@ -204,6 +220,76 @@ static void intel_cx0_rmw(struct drm_i915_private *i915, 
enum port port,
}
 }
 
+/*
+ * Prepare HW for CX0 phy transactions.
+ *
+ * It is required that PSR and DC5/6 are disabled before any CX0 message
+ * bus transaction is executed.
+ */
+static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder 
*encoder)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_pause(intel_dp);
+   return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
+}
+
+static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder, 
intel_wakeref_t wakeref)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   intel_psr_resume(intel_dp);
+   intel_display_power_put(i915, POWER_DOMAIN_DC_OFF, wakeref);
+}
+
+void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+   bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
+   enum intel_cx0_lanes master_lane = lane_reversal ? INTEL_CX0_LANE1 :
+INTEL_CX0_LANE0;
+   const struct intel_ddi_buf_trans *trans;
+   intel_wakeref_t wakeref;
+   int n_entries, ln;
+
+   wakeref = intel_cx0_phy_transaction_begin(encoder);
+
+   trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
+   if (drm_WARN_ON_ONCE(&i915->drm, !trans))
+   return;
+
+   intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES, 
PHY_C10_VDR_CONTROL(1),
+ 0, C10_VDR_CTRL_MSGBUS_ACCESS, MB_WRITE_COMMITTED);
+
+   for (ln = 0; ln < 4; ln++) {
+   int level = intel_ddi_level(encoder, crtc_state, ln);
+   int lane, tx;
+
+   lane = ln / 2;
+   tx = ln % 2 + 1;
+
+   intel_cx0_rmw(i915, encoder->port, lane, PHY_CX0_TX_CONTROL(tx, 
2),
+ C10_PHY_VSWING_PREEMPH_MASK,
+ 
C10_PHY_VSWING_PREEMPH(trans->entries[level].direct.preemph),
+ MB_WRITE_COMMITTED);
+   intel_cx0_rmw(i915, encoder->port, lane, PHY_CX0_TX_CONTROL(tx, 
8),
+ C10_PHY_VSWING_LEVEL_MASK,
+ 
C10_PHY_VSWING_LEVEL(trans->entries[l

Re: [Intel-gfx] [PATCH] drm/i915/gt: Flush to global observation point before breadcrumb write

[Andi Shyti]

Hi Nirmoy,

> From: Prathap Kumar Valsan 
> 
> Add flag to pipecontrol instruction to ensure in-flight writes are
> flushed to global observation point. Also split the pipecontrol
> instruction like we have in gen8.
> 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/5886
> Signed-off-by: Prathap Kumar Valsan 
> Signed-off-by: Nirmoy Das 

pushed in drm-intel-gt-next.

Thanks,
Andi

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Reject excessive dotclocks early (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Reject excessive dotclocks early (rev2)
URL   : https://patchwork.freedesktop.org/series/109141/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109141v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (2): shard-dg1 shard-tglu 
  Missing(1): shard-rkl 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@gem_mmap_offset@ptrace@lmem0-fixed} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109141v2/shard-dg1-17/igt@gem_mmap_offset@ptr...@lmem0-fixed.html

  
New tests
-

  New tests have been introduced between CI_DRM_12193_full and 
Patchwork_109141v2_full:

### New IGT tests (42) ###

  * igt@gem_mmap_offset@ptrace@lmem0-fixed:
- Statuses : 1 fail(s)
- Exec time: [0.02] s

  * igt@gem_mmap_offset@ptrace@smem0-fixed:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_color@legacy-gamma-reset@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.41] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.23] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.24] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@atomic_implicit_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@empty_lease@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lease_invalid_connector@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@lease_invalid_connector@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_revoke@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.26] s

  * igt@kms_lease@lease_revoke@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.10] s

  * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lessee_list@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@lessee_list@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lessee_list@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lessee_list@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.34] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.16] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.17] s

  * igt@kms_lease@page_flip_implicit_plane@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.16] s

  * igt@kms_lease@simple_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.47] s

  * igt@kms_lease@simple_lease@pipe-b-hdmi-a-4:
- Statuses : 

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

[Niranjana Vishwanathapura]

On Thu, Sep 29, 2022 at 11:51:51AM +0100, Matthew Auld wrote:

On 29/09/2022 10:03, Matthew Auld wrote:

On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:

On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c    | 306 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
 drivers/gpu/drm/i915/i915_driver.c    |   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 112 +++
 10 files changed, 495 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
 gem/i915_gem_ttm_move.o \
 gem/i915_gem_ttm_pm.o \
 gem/i915_gem_userptr.o \
+    gem/i915_gem_vm_bind_object.o \
 gem/i915_gem_wait.o \
 gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct 
i915_execbuffer *eb)

 if (unlikely(IS_ERR(ctx)))
 return PTR_ERR(ctx);
+    if (ctx->vm->vm_bind_mode) {
+    i915_gem_context_put(ctx);
+    return -EOPNOTSUPP;
+    }
+
 eb->gem_context = ctx;
 if (i915_gem_context_has_full_ppgtt(ctx))
 eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h

new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git 
a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+ START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to 
bind/unbind GEM buffer
+ * objects (BOs) or sections of a BOs at specified GPU 
virtual addresses on a
+ * specified address space (VM). Multiple mappings can map to 
the same physical
+ * pages of an object (aliasing). These mappings (also 
referred to as persistent
+ * mappings) will be persistent across multiple GPU 
submissions (execbuf calls)
+ * issued by the UMD, without user having to provide a list 
of all required
+ * mappings during each submission (as required by older 
execbuf mode).

+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline 
out fence for

+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via 
I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an 
address space (VM)
+ * during VM creation time via 
I915_VM_CREATE_FLAGS_USE_VM_BIND extension.

+ *
+ * VM_BIND/UNBIND ioctl

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

[Tvrtko Ursulin]

Hi Dave, Daniel,

A few fixes for the upcoming merge window. Not many but most are pretty
important.

Another rather important one is missing due being too conflicty, but will
arrive via drm-intel-fixes (7738be973fc4 ("drm/i915/gt: Perf_limit_reasons
are only available for Gen11+")).

Regards,

Tvrtko

drm-intel-next-fixes-2022-09-29:
- Fix release build bug in 'remove GuC log size module parameters' (John 
Harrison)
- Remove ipc_enabled from struct drm_i915_private (Jani Nikula)
- Do not cleanup obj with NULL bo->resource (Nirmoy Das)
- Fix device info for devices without display (Jani Nikula)
- Force DPLL calculation for TC ports after readout (Ville Syrjälä)
- Use i915_vm_put on ppgtt_create error paths (Chris Wilson)
The following changes since commit 320305923c88258ce50c75bf721e9bf2e420ab27:

  Merge tag 'du-next-20220907' of git://linuxtv.org/pinchartl/media into 
drm-next (2022-09-23 03:52:08 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2022-09-29

for you to fetch changes up to 20e377e7b2e7c327039f10db80ba5bcc1f6c882d:

  drm/i915/gt: Use i915_vm_put on ppgtt_create error paths (2022-09-27 11:05:33 
+0100)


- Fix release build bug in 'remove GuC log size module parameters' (John 
Harrison)
- Remove ipc_enabled from struct drm_i915_private (Jani Nikula)
- Do not cleanup obj with NULL bo->resource (Nirmoy Das)
- Fix device info for devices without display (Jani Nikula)
- Force DPLL calculation for TC ports after readout (Ville Syrjälä)
- Use i915_vm_put on ppgtt_create error paths (Chris Wilson)


Chris Wilson (1):
  drm/i915/gt: Use i915_vm_put on ppgtt_create error paths

Jani Nikula (2):
  drm/i915/display: remove ipc_enabled from struct drm_i915_private
  drm/i915: fix device info for devices without display

John Harrison (1):
  drm/i915/guc: Fix release build bug in 'remove log size module parameters'

Nirmoy Das (1):
  drm/i915: Do not cleanup obj with NULL bo->resource

Ville Syrjälä (1):
  drm/i915: Force DPLL calculation for TC ports after readout

 drivers/gpu/drm/i915/display/intel_ddi.c   | 18 --
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c|  2 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c   | 16 -
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c   | 58 +++---
 drivers/gpu/drm/i915/gt/intel_gtt.c|  3 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 25 +
 drivers/gpu/drm/i915/i915_drv.h|  2 --
 drivers/gpu/drm/i915/i915_pci.c| 11 +++---
 drivers/gpu/drm/i915/intel_device_info.c   |  6 
 9 files changed, 70 insertions(+), 71 deletions(-)

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

[Ceraolo Spurio, Daniele]

On 9/29/2022 3:40 AM, Tvrtko Ursulin wrote:


On 29/09/2022 10:49, Andrzej Hajda wrote:

On 29.09.2022 10:22, Tvrtko Ursulin wrote:

On 28/09/2022 19:27, John Harrison wrote:

On 9/28/2022 00:19, Tvrtko Ursulin wrote:

On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:

On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote:

On 27/09/2022 07:49, Andrzej Hajda wrote:

On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:

On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on 
DG2), so it should
be avoided if possible. Context reset triggered by context 
removal is a

good example.
With this patch multiple igt tests will not timeout and 
should run faster.


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from 
any of

the GuC folks? Daniele, John?

Andi



---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void 
guc_handle_context_reset(struct intel_guc *guc,

  trace_intel_context_reset(ce);
    if (likely(!intel_context_is_banned(ce))) {
-    capture_error_state(guc, ce);
+    if (!intel_context_is_exiting(ce))
+    capture_error_state(guc, ce);


I am not sure here - if we have a persistent context which 
caused a GPU hang I'd expect we'd still want error capture.


What causes the reset in the affected IGTs? Always preemption 
timeout?



guc_context_replay(ce);


You definitely don't want to replay requests of a context that 
is going away.


My intention was to just avoid error capture, but that's even 
better, only condition change:

-        if (likely(!intel_context_is_banned(ce))) {
+       if (likely(intel_context_is_schedulable(ce)))  {


Yes that helper was intended to be used for contexts which 
should not be scheduled post exit or ban.


Daniele - you say there are some misses in the GuC backend. 
Should most, or even all in intel_guc_submission.c be converted 
to use intel_context_is_schedulable? My idea indeed was that 
"ban" should be a level up from the backends. Backend should 
only distinguish between "should I run this or not", and not the 
reason.


I think that all of them should be updated, but I'd like Matt B 
to confirm as he's more familiar with the code than me.


Right, that sounds plausible to me as well.

One thing I forgot to mention - the only place where backend can 
care between "schedulable" and "banned" is when it picks the 
preempt timeout for non-schedulable contexts. This is to only 
apply the strict 1ms to banned (so bad or naught contexts), while 
the ones which are exiting cleanly get the full preempt timeout as 
otherwise configured. This solves the ugly user experience quirk 
where GPU resets/errors were logged upon exit/Ctrl-C of a well 
behaving application (using non-persistent contexts). Hopefully 
GuC can match that behaviour so customers stay happy.


Regards,

Tvrtko


The whole revoke vs ban thing seems broken to me.

First of all, if the user hits Ctrl+C we need to kill the context 
off immediately. That is a fundamental customer requirement. Render 
and compute engines have a 7.5s pre-emption timeout. The user 
should not have to wait 7.5s for a context to be removed from the 
system when they have explicitly killed it themselves. Even the 
regular timeout of 640ms is borderline a long time to wait. And 
note that there is an ongoing request/requirement to increase that 
to 1900ms.


Under what circumstances would a user expect anything sensible to 
happen after a Ctrl+C in terms of things finishing their rendering 
and display nice pretty images? They killed the app. They want it 
dead. We should be getting it off the hardware as quickly as 
possible. If you are really concerned about resets causing 
collateral damage then maybe bump the termination timeout from 1ms 
up to 10ms, maybe at most 100ms. If an app is 'well behaved' then 
it should cleanly exit within 10ms. But if it is bad (which is 
almost certainly the case if the user is manually and explicitly 
killing it) then it needs to be killed because it is not going to 
gracefully exit.


Right.. I had it like that initially (lower timeout - I think 20ms 
or so, patch history on the mailing list would know for sure), but

Re: [Intel-gfx] [PATCH 06/16] drm/i915/vm_bind: Support for VM private BOs

[Niranjana Vishwanathapura]

On Wed, Sep 28, 2022 at 06:54:27PM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object update for all private BOs vs list of
dma_resv objects update for shared BOs, in the execbuf path.

VM private BOs can be only mapped on specified VM and cannot be dmabuf
exported. Also, they are supported only in vm_bind mode.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c| 41 ++-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  6 +++
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  4 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  3 ++
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  3 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  3 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c|  9 
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  4 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  2 +
 drivers/gpu/drm/i915/i915_vma.c   |  1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  2 +
 include/uapi/drm/i915_drm.h   | 30 ++
 12 files changed, 106 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 4aa7b5582b8e..692d95ef5d3e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,6 +11,7 @@
 #include "pxp/intel_pxp.h"
 #include "i915_drv.h"
+#include "i915_gem_context.h"
 #include "i915_gem_create.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
@@ -252,6 +253,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+   u32 vm_id;
 };
 static void repr_placements(char *buf, size_t size,
@@ -401,9 +403,24 @@ static int ext_set_protected(struct i915_user_extension 
__user *base, void *data
return 0;
 }
+static int ext_set_vm_private(struct i915_user_extension __user *base,
+ void *data)
+{
+   struct drm_i915_gem_create_ext_vm_private ext;
+   struct create_ext *ext_data = data;
+
+   if (copy_from_user(&ext, base, sizeof(ext)))
+   return -EFAULT;
+
+   ext_data->vm_id = ext.vm_id;
+
+   return 0;
+}
+
 static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+   [I915_GEM_CREATE_EXT_VM_PRIVATE] = ext_set_vm_private,
 };
 /**
@@ -419,6 +436,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_create_ext *args = data;
struct create_ext ext_data = { .i915 = i915 };
+   struct i915_address_space *vm = NULL;
struct drm_i915_gem_object *obj;
int ret;
@@ -432,6 +450,12 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (ret)
return ret;
+   if (ext_data.vm_id) {
+   vm = i915_gem_vm_lookup(file->driver_priv, ext_data.vm_id);
+   if (unlikely(!vm))
+   return -ENOENT;
+   }
+
if (!ext_data.n_placements) {
ext_data.placements[0] =
intel_memory_region_by_type(i915, INTEL_MEMORY_SYSTEM);
@@ -458,8 +482,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.placements,
ext_data.n_placements,
ext_data.flags);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
+   if (IS_ERR(obj)) {
+   ret = PTR_ERR(obj);
+   goto vm_put;
+   }
+
+   if (vm) {
+   obj->base.resv = vm->root_obj->base.resv;
+   obj->priv_root = i915_gem_object_get(vm->root_obj);
+   i915_vm_put(vm);
+   }
return i915_gem_publish(obj, file, &args->size, &args->handle);
+vm_put:
+   if (vm)
+   i915_vm_put(vm);
+
+   return ret;
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..6433173c3e84 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -218,6 +218,12 @@ struct dma_buf *i915_gem_prime_export(struct 
drm_gem_object *gem_obj, int flags)
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+   if (obj->priv_root) {
+   drm_dbg(obj->base.dev,
+   "Exporting VM private objects is not allowed\n");
+   return ERR_PT

[Intel-gfx] [PULL] drm-misc-fixes

[Thomas Zimmermann]

Hi Dave and Daniel,

this is the PR for drm-misc-fixes for this week.

Best regards
Thomas

drm-misc-fixes-2022-09-29:
Short summary of fixes pull:

 * bridge/analogix: Revert earlier suspend fix
 * bridge/lt8912b: Fix corrupt display output
The following changes since commit d8a79c03054911c375a2252627a429c9bc4615b6:

  drm/hisilicon: Add depends on MMU (2022-09-20 11:15:09 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-09-29

for you to fetch changes up to cc62d98bd56d45de4531844ca23913a15136c05b:

  Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in 
suspend/resume time" (2022-09-23 07:15:18 -0700)


Short summary of fixes pull:

 * bridge/analogix: Revert earlier suspend fix
 * bridge/lt8912b: Fix corrupt display output


Brian Norris (1):
  Revert "drm: bridge: analogix/dp: add panel prepare/unprepare in 
suspend/resume time"

Francesco Dolcini (1):
  drm/bridge: lt8912b: fix corrupted image output

Philippe Schenker (2):
  drm/bridge: lt8912b: add vsync hsync
  drm/bridge: lt8912b: set hdmi or dvi mode

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 -
 drivers/gpu/drm/bridge/lontium-lt8912b.c   | 13 +++--
 2 files changed, 11 insertions(+), 15 deletions(-)

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

Re: [Intel-gfx] [PATCH 12/16] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

[Matthew Auld]

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.

Legacy features like relocations etc are not supported by execbuf3.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/Makefile |   1 +
  .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 571 ++
  drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
  drivers/gpu/drm/i915/i915_driver.c|   1 +
  include/uapi/drm/i915_drm.h   |  61 ++
  5 files changed, 636 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bf952f478555..3473ee5825bb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..92af88bc8deb
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,571 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB 
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+   struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer3 *args;
+
+   struct intel_gt *gt;
+   struct intel_context *context;
+   struct i915_gem_context *gem_context;
+
+   struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
+   struct dma_fence *composite_fence;
+
+   struct i915_gem_ww_ctx ww;
+
+   unsigned int num_batches;
+   u64 batch_addresses[MAX_ENGI

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Define engine context layouts

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Define engine context layouts
URL   : https://patchwork.freedesktop.org/series/109190/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109190v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (10 -> 11)
--

  Additional (2): shard-dg1 shard-tglu 
  Missing(1): shard-rkl 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@gem_mmap_offset@ptrace@lmem0-fixed} (NEW):
- {shard-dg1}:NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109190v1/shard-dg1-19/igt@gem_mmap_offset@ptr...@lmem0-fixed.html

  
New tests
-

  New tests have been introduced between CI_DRM_12193_full and 
Patchwork_109190v1_full:

### New IGT tests (35) ###

  * igt@gem_mmap_offset@ptrace@lmem0-fixed:
- Statuses : 1 fail(s)
- Exec time: [0.02] s

  * igt@gem_mmap_offset@ptrace@smem0-fixed:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_color@ctm-max@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.44] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.41] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.23] s

  * igt@kms_cursor_crc@cursor-rapid-movement-128x42@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.24] s

  * igt@kms_lease@empty_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@empty_lease@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@empty_lease@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lease_invalid_connector@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_connector@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_connector@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.15] s

  * igt@kms_lease@lease_invalid_crtc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_crtc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_plane@pipe-a-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.13] s

  * igt@kms_lease@lease_invalid_plane@pipe-b-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_plane@pipe-c-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_invalid_plane@pipe-d-hdmi-a-3:
- Statuses : 1 pass(s)
- Exec time: [0.02] s

  * igt@kms_lease@lease_revoke@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  * igt@kms_lease@lease_revoke@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.11] s

  * igt@kms_lease@lessee_list@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.14] s

  * igt@kms_lease@lessee_list@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lessee_list@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@lessee_list@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.03] s

  * igt@kms_lease@simple_lease@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.46] s

  * igt@kms_lease@simple_lease@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.26] s

  * igt@kms_lease@simple_lease@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.28] s

  * igt@kms_lease@simple_lease@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.25] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][2]

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

[Rodrigo Vivi]

Hi Dave and Daniel,

Here goes drm-intel-fixes-2022-09-29:

- Restrict forced preemption to the active context (Chris)
- Restrict perf_limit_reasons to the supported platforms - gen11+ (Ashutosh)

Thanks,
Rodrigo.

The following changes since commit f76349cf41451c5c42a99f18a9163377e4b364ff:

  Linux 6.0-rc7 (2022-09-25 14:01:02 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-09-29

for you to fetch changes up to 7738be973fc4e2ba22154fafd3a5d7b9666f9abf:

  drm/i915/gt: Perf_limit_reasons are only available for Gen11+ (2022-09-28 
16:39:26 -0400)


- Restrict forced preemption to the active context (Chris)
- Restrict perf_limit_reasons to the supported platforms - gen11+ (Ashutosh)


Ashutosh Dixit (1):
  drm/i915/gt: Perf_limit_reasons are only available for Gen11+

Chris Wilson (1):
  drm/i915/gt: Restrict forced preemption to the active context

 drivers/gpu/drm/i915/gt/intel_engine_types.h| 15 +++
 .../gpu/drm/i915/gt/intel_execlists_submission.c| 21 -
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 15 +++
 3 files changed, 46 insertions(+), 5 deletions(-)

Re: [Intel-gfx] [PATCH 12/16] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

[Niranjana Vishwanathapura]

On Thu, Sep 29, 2022 at 04:00:47PM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.

Legacy features like relocations etc are not supported by execbuf3.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 571 ++
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
 drivers/gpu/drm/i915/i915_driver.c|   1 +
 include/uapi/drm/i915_drm.h   |  61 ++
 5 files changed, 636 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bf952f478555..3473ee5825bb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..92af88bc8deb
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,571 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB 
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */
+struct i915_execbuffer {
+   struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer3 *args;
+
+   struct intel_gt *gt;
+   struct intel_context *context;
+   struct i915_gem_context *gem_context;
+
+   struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
+   struct dma_fence *composite_fence;
+
+   struct i915_gem_ww_ctx ww;
+
+   unsign

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Make the heartbeat play nice with long pre-emption timeouts

[John Harrison]

On 9/29/2022 00:42, Tvrtko Ursulin wrote:

On 29/09/2022 03:18, john.c.harri...@intel.com wrote:

From: John Harrison 

Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence the
next patch will re-enable the timeout but bumped up by an order of
magnitude.

However, the heartbeat might not respect that. Depending upon current
activity, a pre-emption to the heartbeat pulse might not even be
attempted until the last heartbeat period. Which means that only one
period is granted for the pre-emption to occur. With the aforesaid
bump, the pre-emption timeout could be significantly larger than this
heartbeat period.

So adjust the heartbeat code to take the pre-emption timeout into
account. When it reaches the final (high priority) period, it now
ensures the delay before hitting reset is bigger than the pre-emption
timeout.

v2: Fix for selftests which adjust the heartbeat period manually.

Signed-off-by: John Harrison 
---
  .../gpu/drm/i915/gt/intel_engine_heartbeat.c  | 19 +++
  1 file changed, 19 insertions(+)

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

index a3698f611f457..823a790a0e2ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -22,9 +22,28 @@
    static bool next_heartbeat(struct intel_engine_cs *engine)
  {
+    struct i915_request *rq;
  long delay;
    delay = READ_ONCE(engine->props.heartbeat_interval_ms);
+
+    rq = engine->heartbeat.systole;
+
+    if (rq && rq->sched.attr.priority >= I915_PRIORITY_BARRIER &&
+    delay == engine->defaults.heartbeat_interval_ms) {


Maybe I forgot but what is the reason for the check against the 
default heartbeat interval?
That's the 'v2: fix for selftests that manually adjust the heartbeat'. 
If something (or someone) has explicitly set an override of the 
heartbeat then it has to be assumed that they know what they are doing, 
and if things don't work any more that's their problem. But if we don't 
respect their override then they won't get the timings they expect and 
the selftest will fail.


John.



Regards,

Tvrtko


+    long longer;
+
+    /*
+ * The final try is at the highest priority possible. Up 
until now
+ * a pre-emption might not even have been attempted. So make 
sure
+ * this last attempt allows enough time for a pre-emption to 
occur.

+ */
+    longer = READ_ONCE(engine->props.preempt_timeout_ms) * 2;
+    longer = intel_clamp_heartbeat_interval_ms(engine, longer);
+    if (longer > delay)
+    delay = longer;
+    }
+
  if (!delay)
  return false;

[Intel-gfx] [PATCH v4 00/30] drm: Analog TV Improvements

[Maxime Ripard]

Hi,

Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.

The named modes support were initially introduced to allow to specify the
analog TV mode to be used.

However, this was causing multiple issues:

  * The mode name parsed on the command line was passed directly to the
driver, which had to figure out which mode it was suppose to match;

  * Figuring that out wasn't really easy, since the video= argument or what
the userspace might not even have a name in the first place, but
instead could have passed a mode with the same timings;

  * The fallback to matching on the timings was mostly working as long as
we were supporting one 525 lines (most likely NSTC) and one 625 lines
(PAL), but couldn't differentiate between two modes with the same
timings (NTSC vs PAL-M vs NSTC-J for example);

  * There was also some overlap with the tv mode property registered by
drm_mode_create_tv_properties(), but named modes weren't interacting
with that property at all.

  * Even though that property was generic, its possible values were
specific to each drivers, which made some generic support difficult.

Thus, I chose to tackle in multiple steps:

  * A new TV mode property was introduced, with generic values, each driver
reporting through a bitmask what standard it supports to the userspace;

  * This option was added to the command line parsing code to be able to
specify it on the kernel command line, and new atomic_check and reset
helpers were created to integrate properly into atomic KMS;

  * The named mode parsing code is now creating a proper display mode for
the given named mode, and the TV standard will thus be part of the
connector state;

  * Two drivers were converted and tested for now (vc4 and sun4i), with
some backward compatibility code to translate the old TV mode to the
new TV mode;

Unit tests were created along the way.

One can switch from NTSC to PAL now using (on vc4)

modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL

Let me know what you think,
Maxime

To: David Airlie 
To: Daniel Vetter 
To: Maarten Lankhorst 
To: Maxime Ripard 
To: Thomas Zimmermann 
To: Emma Anholt 
To: Jani Nikula 
To: Joonas Lahtinen 
To: Rodrigo Vivi 
To: Tvrtko Ursulin 
To: Ben Skeggs 
To: Karol Herbst 
To: Lyude Paul 
To: Chen-Yu Tsai 
To: Jernej Skrabec 
To: Samuel Holland 
Cc: Geert Uytterhoeven 
Cc: Mateusz Kwiatkowski 
Cc: "Noralf Trønnes" 
Cc: Dave Stevenson 
Cc: Dom Cobley 
Cc: Phil Elwell 
Cc: 
Cc: linux-ker...@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-su...@lists.linux.dev
Cc: Hans de Goede 
Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Removed the unused TV Standard property documentation
- Added the TV Mode property documentation to kms-properties.csv
- Fixed the documentation of drm_mode_create_tv_properties()
- Removed DRM_MODE_TV_MODE_NONE
- Reworded the line length check comment in drm_mode_analog_tv tests
- Switched to HZ_PER_KHZ in drm_mode_analog_tv tests
- Reworked drm_mode_analog_tv to fill our mode using the previously computed
  timings
- Added the command-line option documentation to modedb.rst
- Improved the Kunit helpers cleanup
- Moved the subconnector documentation renaming to the proper patch
- Added the various review tags
- Removed the count variable in vc4_vec_connector_get_modes
- Rebased on drm-misc-next-2022-09-23 and fixed a merge conflict
- Folded all the named mode parsing improvements in a single patch
- Link to v3: 
https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v2-0-f733a0ed9...@cerno.tech

Changes in v3:
- Applied some of the fixes to vc4 and sun4i
- Renamed the old TV mode property to legacy_mode
- Fixed a bunch of bisection errors
- Removed most of the redundant TV modes
- Added a new None TV mode to not fall back on NTSC by mistake
- Fixed the mode generation function to match better what is expected
- Added some logging to the mode generation function
- Split the improvements to the named mode parsing logic into separate patches
- Added more checks to the TV atomic_check helper
- Link to v2: 
https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v2-0-459522d65...@cerno.tech/

Changes in v2:
- Kept the older TV mode property as legacy so we can keep the old drivers 
functional
- Renamed the tv_norm property to tv_mode
- Added a function to create PAL and NTSC compatible display modes
- Added some helpers to instantiate a mock DRM device in Kunit
- More Kunit tests
- Removed the HD analog TV modes
- Renamed some of the tests
- Renamed some of the named modes
- Fixed typos in commit logs
- Added the various tags
- Link to v1: 
https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-0-3d53ae722...@cerno.tech/

---
Geert Uytterhoev

[Intel-gfx] [PATCH v4 01/30] drm/docs: Remove unused TV Standard property

[Maxime Ripard]

That property is not used or exposed by any driver in the kernel. Remove
it from the documentation.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- New patch
---
 Documentation/gpu/kms-properties.csv | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 07ed22ea3bd6..45c12e3e82f4 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -91,7 +91,6 @@ omap,Generic,“zorder”,RANGE,"Min=0, Max=3","CRTC, Plane",TBD
 qxl,Generic,"“hotplug_mode_update""",RANGE,"Min=0, Max=1",Connector,TBD
 radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
 ,DAC enable load detect,“load detection”,RANGE,"Min=0, Max=1",Connector,TBD
-,TV Standard,"""tv standard""",ENUM,"{ ""ntsc"", ""pal"", ""pal-m"", 
""pal-60"", ""ntsc-j"" , ""scart-pal"", ""pal-cn"", ""secam"" }",Connector,TBD
 ,legacy TMDS PLL detect,"""tmds_pll""",ENUM,"{ ""driver"", ""bios"" }",-,TBD
 ,Underscan,"""underscan""",ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
 ,,"""underscan hborder""",RANGE,"Min=0, Max=128",Connector,TBD

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 02/30] drm/tests: Order Kunit tests in Makefile

[Maxime Ripard]

Since we've recently added a ton of tests, the list starts to be a bit
of a mess and creates unneeded conflicts.

Let's order it alphabetically.

Acked-by: Thomas Zimmermann 
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/tests/Makefile | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index 91b70f7d2769..2d9f49b62ecb 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -1,5 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o 
drm_damage_helper_test.o \
-   drm_cmdline_parser_test.o drm_rect_test.o drm_format_test.o 
drm_plane_helper_test.o \
-   drm_dp_mst_helper_test.o drm_framebuffer_test.o drm_buddy_test.o 
drm_mm_test.o
+obj-$(CONFIG_DRM_KUNIT_TEST) += \
+   drm_buddy_test.o \
+   drm_cmdline_parser_test.o \
+   drm_damage_helper_test.o \
+   drm_dp_mst_helper_test.o \
+   drm_format_helper_test.o \
+   drm_format_test.o \
+   drm_framebuffer_test.o \
+   drm_mm_test.o \
+   drm_plane_helper_test.o \
+   drm_rect_test.o

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 03/30] drm/tests: Add Kunit Helpers

[Maxime Ripard]

As the number of kunit tests in KMS grows further, we start to have
multiple test suites that, for example, need to register a mock DRM
driver to interact with the KMS function they are supposed to test.

Let's add a file meant to provide those kind of helpers to avoid
duplication.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Simplified the DRM device cleanup patch using devm_drm_dev_alloc()
---
 drivers/gpu/drm/tests/Makefile|  1 +
 drivers/gpu/drm/tests/drm_kunit_helpers.c | 61 +++
 drivers/gpu/drm/tests/drm_kunit_helpers.h |  9 +
 3 files changed, 71 insertions(+)

diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index 2d9f49b62ecb..b29ef1085cad 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_format_helper_test.o \
drm_format_test.o \
drm_framebuffer_test.o \
+   drm_kunit_helpers.o \
drm_mm_test.o \
drm_plane_helper_test.o \
drm_rect_test.o
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c 
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
new file mode 100644
index ..3524d6a1fa9a
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -0,0 +1,61 @@
+#include 
+#include 
+
+#include 
+
+#include 
+
+struct kunit_dev {
+   struct drm_device base;
+};
+
+static const struct drm_mode_config_funcs drm_mode_config_funcs = {
+};
+
+static const struct drm_driver drm_mode_driver = {
+};
+
+static int dev_init(struct kunit_resource *res, void *ptr)
+{
+   char *name = ptr;
+   struct device *dev;
+
+   dev = root_device_register(name);
+   if (IS_ERR(dev))
+   return PTR_ERR(dev);
+
+   res->data = dev;
+   return 0;
+}
+
+static void dev_free(struct kunit_resource *res)
+{
+   struct device *dev = res->data;
+
+   root_device_unregister(dev);
+}
+
+struct drm_device *drm_kunit_device_init(struct kunit *test, char *name)
+{
+   struct kunit_dev *kdev;
+   struct drm_device *drm;
+   struct device *dev;
+   int ret;
+
+   dev = kunit_alloc_resource(test, dev_init, dev_free, GFP_KERNEL, name);
+   if (!dev)
+   return ERR_PTR(-ENOMEM);
+
+   kdev = devm_drm_dev_alloc(dev, &drm_mode_driver, struct kunit_dev, 
base);
+   if (IS_ERR(kdev))
+   return ERR_CAST(kdev);
+
+   drm = &kdev->base;
+   drm->mode_config.funcs = &drm_mode_config_funcs;
+
+   ret = drmm_mode_config_init(drm);
+   if (ret)
+   return ERR_PTR(ret);
+
+   return drm;
+}
diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.h 
b/drivers/gpu/drm/tests/drm_kunit_helpers.h
new file mode 100644
index ..a9354f9bda4e
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.h
@@ -0,0 +1,9 @@
+#ifndef DRM_KUNIT_HELPERS_H_
+#define DRM_KUNIT_HELPERS_H_
+
+struct drm_device;
+struct kunit;
+
+struct drm_device *drm_kunit_device_init(struct kunit *test, char *name);
+
+#endif // DRM_KUNIT_HELPERS_H_

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 04/30] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity

[Maxime Ripard]

We currently have two sets of TV properties.

The first one is there to deal with analog TV properties, creating
properties such as the TV mode, subconnectors, saturation, hue and so on.
It's created by calling the drm_mode_create_tv_properties() function.

The second one is there to deal with properties that might be useful on a
TV, creating the overscan margins for example. It's created by calling the
drm_mode_create_tv_margin_properties().

However, we also have a drm_atomic_helper_connector_tv_reset() function
that will reset the TV margin properties to their default values, and thus
is supposed to be called for the latter set. This creates an ambiguity due
to the inconsistent naming.

We can thus rename the drm_atomic_helper_connector_tv_reset() function to
drm_atomic_helper_connector_tv_margins_reset() to remove that ambiguity
and hopefully make it more obvious.

Acked-by: Thomas Zimmermann 
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Removed the unrelated subconnector documentation name change
---
 drivers/gpu/drm/drm_atomic_state_helper.c | 6 +++---
 drivers/gpu/drm/gud/gud_connector.c   | 2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
 include/drm/drm_atomic_state_helper.h | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index bf31b9d92094..dfb57217253b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -464,12 +464,12 @@ void drm_atomic_helper_connector_reset(struct 
drm_connector *connector)
 EXPORT_SYMBOL(drm_atomic_helper_connector_reset);
 
 /**
- * drm_atomic_helper_connector_tv_reset - Resets TV connector properties
+ * drm_atomic_helper_connector_tv_margins_reset - Resets TV connector 
properties
  * @connector: DRM connector
  *
  * Resets the TV-related properties attached to a connector.
  */
-void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
+void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector 
*connector)
 {
struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
struct drm_connector_state *state = connector->state;
@@ -479,7 +479,7 @@ void drm_atomic_helper_connector_tv_reset(struct 
drm_connector *connector)
state->tv.margins.top = cmdline->tv_margins.top;
state->tv.margins.bottom = cmdline->tv_margins.bottom;
 }
-EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
 
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
diff --git a/drivers/gpu/drm/gud/gud_connector.c 
b/drivers/gpu/drm/gud/gud_connector.c
index d0addd478815..fa636206f232 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -355,7 +355,7 @@ static void gud_connector_reset(struct drm_connector 
*connector)
drm_atomic_helper_connector_reset(connector);
connector->state->tv = gconn->initial_tv_state;
/* Set margins from command line */
-   drm_atomic_helper_connector_tv_reset(connector);
+   drm_atomic_helper_connector_tv_margins_reset(connector);
if (gconn->initial_brightness >= 0)
connector->state->tv.brightness = gconn->initial_brightness;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 64f9feabf43e..99908137dbe7 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -542,7 +542,7 @@ static void vc4_hdmi_connector_reset(struct drm_connector 
*connector)
new_state->base.max_bpc = 8;
new_state->base.max_requested_bpc = 8;
new_state->output_format = VC4_HDMI_OUTPUT_RGB;
-   drm_atomic_helper_connector_tv_reset(connector);
+   drm_atomic_helper_connector_tv_margins_reset(connector);
 }
 
 static struct drm_connector_state *
diff --git a/include/drm/drm_atomic_state_helper.h 
b/include/drm/drm_atomic_state_helper.h
index 3f8f1d627f7c..192766656b88 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -70,7 +70,7 @@ void __drm_atomic_helper_connector_state_reset(struct 
drm_connector_state *conn_
 void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
 struct drm_connector_state 
*conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
-void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector 
*connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
   struct drm_connector_state *state);

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 05/30] drm/connector: Rename subconnector state variable

[Maxime Ripard]

There is two TV subconnector related properties registered by
drm_mode_create_tv_properties(): subconnector and select subconnector.

While the select subconnector property is stored in the kernel by the
drm_tv_connector_state structure, the subconnector property isn't stored
anywhere.

Worse, the select subconnector property is stored in a field called
subconnector, creating some ambiguity about which property content we're
accessing.

Let's rename that field to one called select_subconnector to make it move
obvious what it's about.

Acked-by: Thomas Zimmermann 
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Added the documentation name update
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
 include/drm/drm_connector.h   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..c74c78a28171 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -687,7 +687,7 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 */
return -EINVAL;
} else if (property == config->tv_select_subconnector_property) {
-   state->tv.subconnector = val;
+   state->tv.select_subconnector = val;
} else if (property == config->tv_left_margin_property) {
state->tv.margins.left = val;
} else if (property == config->tv_right_margin_property) {
@@ -795,7 +795,7 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
else
*val = connector->dpms;
} else if (property == config->tv_select_subconnector_property) {
-   *val = state->tv.subconnector;
+   *val = state->tv.select_subconnector;
} else if (property == config->tv_left_margin_property) {
*val = state->tv.margins.left;
} else if (property == config->tv_right_margin_property) {
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 248206bbd975..60b5662dec7c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -692,7 +692,7 @@ struct drm_connector_tv_margins {
 
 /**
  * struct drm_tv_connector_state - TV connector related states
- * @subconnector: selected subconnector
+ * @select_subconnector: selected subconnector
  * @margins: TV margins
  * @mode: TV mode
  * @brightness: brightness in percent
@@ -703,7 +703,7 @@ struct drm_connector_tv_margins {
  * @hue: hue in percent
  */
 struct drm_tv_connector_state {
-   enum drm_mode_subconnector subconnector;
+   enum drm_mode_subconnector select_subconnector;
struct drm_connector_tv_margins margins;
unsigned int mode;
unsigned int brightness;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 06/30] drm/atomic: Add TV subconnector property to get/set_property

[Maxime Ripard]

The subconnector property was created by drm_mode_create_tv_properties(),
but wasn't exposed to the userspace through the generic
atomic_get/set_property implementation, and wasn't stored in any generic
state structure.

Let's solve this.

Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 
 include/drm/drm_connector.h   | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c74c78a28171..c06d0639d552 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -688,6 +688,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
} else if (property == config->tv_select_subconnector_property) {
state->tv.select_subconnector = val;
+   } else if (property == config->tv_subconnector_property) {
+   state->tv.subconnector = val;
} else if (property == config->tv_left_margin_property) {
state->tv.margins.left = val;
} else if (property == config->tv_right_margin_property) {
@@ -796,6 +798,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = connector->dpms;
} else if (property == config->tv_select_subconnector_property) {
*val = state->tv.select_subconnector;
+   } else if (property == config->tv_subconnector_property) {
+   *val = state->tv.subconnector;
} else if (property == config->tv_left_margin_property) {
*val = state->tv.margins.left;
} else if (property == config->tv_right_margin_property) {
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 60b5662dec7c..1d5e3cccb9e3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -693,6 +693,7 @@ struct drm_connector_tv_margins {
 /**
  * struct drm_tv_connector_state - TV connector related states
  * @select_subconnector: selected subconnector
+ * @subconnector: detected subconnector
  * @margins: TV margins
  * @mode: TV mode
  * @brightness: brightness in percent
@@ -704,6 +705,7 @@ struct drm_connector_tv_margins {
  */
 struct drm_tv_connector_state {
enum drm_mode_subconnector select_subconnector;
+   enum drm_mode_subconnector subconnector;
struct drm_connector_tv_margins margins;
unsigned int mode;
unsigned int brightness;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 07/30] drm/connector: Rename legacy TV property

[Maxime Ripard]

The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.

Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away from it.

Acked-by: Thomas Zimmermann 
Reviewed-by: Lyude Paul  # nouveau
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 8 
 drivers/gpu/drm/drm_connector.c   | 6 +++---
 drivers/gpu/drm/gud/gud_connector.c   | 6 +++---
 drivers/gpu/drm/i2c/ch7006_drv.c  | 4 ++--
 drivers/gpu/drm/i915/display/intel_tv.c   | 3 ++-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++--
 drivers/gpu/drm/vc4/vc4_vec.c | 8 
 include/drm/drm_connector.h   | 4 ++--
 include/drm/drm_mode_config.h | 6 --
 9 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c06d0639d552..7f2b9a07fbdf 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -698,8 +698,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->tv.margins.top = val;
} else if (property == config->tv_bottom_margin_property) {
state->tv.margins.bottom = val;
-   } else if (property == config->tv_mode_property) {
-   state->tv.mode = val;
+   } else if (property == config->legacy_tv_mode_property) {
+   state->tv.legacy_mode = val;
} else if (property == config->tv_brightness_property) {
state->tv.brightness = val;
} else if (property == config->tv_contrast_property) {
@@ -808,8 +808,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->tv.margins.top;
} else if (property == config->tv_bottom_margin_property) {
*val = state->tv.margins.bottom;
-   } else if (property == config->tv_mode_property) {
-   *val = state->tv.mode;
+   } else if (property == config->legacy_tv_mode_property) {
+   *val = state->tv.legacy_mode;
} else if (property == config->tv_brightness_property) {
*val = state->tv.brightness;
} else if (property == config->tv_contrast_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e3142c8142b3..ede6025638d7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1686,14 +1686,14 @@ int drm_mode_create_tv_properties(struct drm_device 
*dev,
if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
 
-   dev->mode_config.tv_mode_property =
+   dev->mode_config.legacy_tv_mode_property =
drm_property_create(dev, DRM_MODE_PROP_ENUM,
"mode", num_modes);
-   if (!dev->mode_config.tv_mode_property)
+   if (!dev->mode_config.legacy_tv_mode_property)
goto nomem;
 
for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.tv_mode_property,
+   drm_property_add_enum(dev->mode_config.legacy_tv_mode_property,
  i, modes[i]);
 
dev->mode_config.tv_brightness_property =
diff --git a/drivers/gpu/drm/gud/gud_connector.c 
b/drivers/gpu/drm/gud/gud_connector.c
index fa636206f232..86e992b2108b 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -303,7 +303,7 @@ static int gud_connector_atomic_check(struct drm_connector 
*connector,
old_state->tv.margins.right != new_state->tv.margins.right ||
old_state->tv.margins.top != new_state->tv.margins.top ||
old_state->tv.margins.bottom != new_state->tv.margins.bottom ||
-   old_state->tv.mode != new_state->tv.mode ||
+   old_state->tv.legacy_mode != new_state->tv.legacy_mode ||
old_state->tv.brightness != new_state->tv.brightness ||
old_state->tv.contrast != new_state->tv.contrast ||
old_state->tv.flicker_reduction != new_state->tv.flicker_reduction 
||
@@ -424,7 +424,7 @@ gud_connector_property_lookup(struct drm_connector 
*connector, u16 prop)
case GUD_PROPERTY_TV_BOTTOM_MARGIN:
return config->tv_bottom_margin_property;
case GUD_PROPERTY_TV_MODE:
-   return config->tv_mode_property;
+   return config->legacy_tv_mode_property;
case GUD_PROPERTY_TV_BRIGHTNESS:
return config->tv_brightness_property;
case GUD_PROPERTY_TV_CONTRAST:
@@ -454,7 +454,7 @@ static unsigned int *gud_connector_tv_state_val(u16 prop, 
struct drm_tv_connecto
case GUD_PROPERTY_TV_BOTTOM_MARGIN:
return &state->margins.bottom;
case GUD_

[Intel-gfx] [PATCH v4 12/30] drm/modes: Only consider bpp and refresh before options

[Maxime Ripard]

Some video= options might have a value that contains a dash. However, the
command line parsing mode considers all dashes as the separator between the
mode and the bpp count.

Let's rework the parsing code a bit to only consider a dash as the bpp
separator if it before a comma, the options separator.

A follow-up patch will add a unit-test for this once such an option is
introduced.

Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 7cf2fe98d7d2..99809ea09ce3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2275,20 +2275,22 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 
name = mode_option;
 
+   /* Locate the start of named options */
+   options_ptr = strchr(name, ',');
+   if (options_ptr)
+   options_off = options_ptr - name;
+   else
+   options_off = strlen(name);
+
/* Try to locate the bpp and refresh specifiers, if any */
-   bpp_ptr = strchr(name, '-');
+   bpp_ptr = strnchr(name, options_off, '-');
if (bpp_ptr)
bpp_off = bpp_ptr - name;
 
-   refresh_ptr = strchr(name, '@');
+   refresh_ptr = strnchr(name, options_off, '@');
if (refresh_ptr)
refresh_off = refresh_ptr - name;
 
-   /* Locate the start of named options */
-   options_ptr = strchr(name, ',');
-   if (options_ptr)
-   options_off = options_ptr - name;
-
/* Locate the end of the name / resolution, and parse it */
if (bpp_ptr) {
mode_end = bpp_off;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 14/30] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

[Maxime Ripard]

drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.

Let's add some unit tests to make sure we're not getting any regressions
there.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Removed MODULE macros
---
 drivers/gpu/drm/drm_client_modeset.c|   4 +
 drivers/gpu/drm/tests/drm_client_modeset_test.c | 105 
 2 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..d553e793e673 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev 
*client, int mode)
return ret;
 }
 EXPORT_SYMBOL(drm_client_modeset_dpms);
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c 
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
new file mode 100644
index ..09dc5acbbc42
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Maxime Ripard 
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm_kunit_helpers.h"
+
+struct drm_client_modeset_test_priv {
+   struct drm_device *drm;
+   struct drm_connector connector;
+};
+
+static int drm_client_modeset_connector_get_modes(struct drm_connector 
*connector)
+{
+   struct drm_display_mode *mode;
+   int count;
+
+   count = drm_add_modes_noedid(connector, 1920, 1200);
+
+   return count;
+}
+
+static const struct drm_connector_helper_funcs 
drm_client_modeset_connector_helper_funcs = {
+   .get_modes = drm_client_modeset_connector_get_modes,
+};
+
+static const struct drm_connector_funcs drm_client_modeset_connector_funcs = {
+};
+
+static int drm_client_modeset_test_init(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv;
+   int ret;
+
+   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+   test->priv = priv;
+
+   priv->drm = drm_kunit_device_init(test, "drm-client-modeset-test");
+   if (IS_ERR(priv->drm))
+   return PTR_ERR(priv->drm);
+
+   ret = drmm_connector_init(priv->drm, &priv->connector,
+ &drm_client_modeset_connector_funcs,
+ DRM_MODE_CONNECTOR_Unknown,
+ NULL);
+   if (ret)
+   return ret;
+   drm_connector_helper_add(&priv->connector, 
&drm_client_modeset_connector_helper_funcs);
+
+   return 0;
+
+}
+
+static void drm_pick_cmdline_res_1920_1080_60(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct drm_connector *connector = &priv->connector;
+   struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+   struct drm_display_mode *expected_mode, *mode;
+   const char *cmdline = "1920x1080@60";
+   int ret;
+
+   expected_mode = drm_mode_find_dmt(priv->drm, 1920, 1080, 60, false);
+   KUNIT_ASSERT_PTR_NE(test, expected_mode, NULL);
+
+   KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+   connector,
+   
cmdline_mode));
+
+   mutex_lock(&drm->mode_config.mutex);
+   ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+   mutex_unlock(&drm->mode_config.mutex);
+   KUNIT_ASSERT_GT(test, ret, 0);
+
+   mode = drm_connector_pick_cmdline_mode(connector);
+   KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+   KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
+}
+
+static struct kunit_case drm_pick_cmdline_tests[] = {
+   KUNIT_CASE(drm_pick_cmdline_res_1920_1080_60),
+   {}
+};
+
+static struct kunit_suite drm_pick_cmdline_test_suite = {
+   .name = "drm_pick_cmdline",
+   .init = drm_client_modeset_test_init,
+   .test_cases = drm_pick_cmdline_tests
+};
+
+kunit_test_suite(drm_pick_cmdline_test_suite);

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 08/30] drm/connector: Only register TV mode property if present

[Maxime Ripard]

The drm_create_tv_properties() will create the TV mode property
unconditionally.

However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.

Acked-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_connector.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ede6025638d7..17a5913cefe3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1686,15 +1686,18 @@ int drm_mode_create_tv_properties(struct drm_device 
*dev,
if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
 
-   dev->mode_config.legacy_tv_mode_property =
-   drm_property_create(dev, DRM_MODE_PROP_ENUM,
-   "mode", num_modes);
-   if (!dev->mode_config.legacy_tv_mode_property)
-   goto nomem;
 
-   for (i = 0; i < num_modes; i++)
-   drm_property_add_enum(dev->mode_config.legacy_tv_mode_property,
- i, modes[i]);
+   if (num_modes) {
+   dev->mode_config.legacy_tv_mode_property =
+   drm_property_create(dev, DRM_MODE_PROP_ENUM,
+   "mode", num_modes);
+   if (!dev->mode_config.legacy_tv_mode_property)
+   goto nomem;
+
+   for (i = 0; i < num_modes; i++)
+   
drm_property_add_enum(dev->mode_config.legacy_tv_mode_property,
+ i, modes[i]);
+   }
 
dev->mode_config.tv_brightness_property =
drm_property_create_range(dev, 0, "brightness", 0, 100);

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 11/30] drm/modes: Add a function to generate analog display modes

[Maxime Ripard]

Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.

Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.

However, analog display usually have fairly loose timings requirements,
the only discrete parameters being the total number of lines and pixel
clock frequency. Thus, we created a function that will create a display
mode from the standard, the pixel frequency and the active area.

Signed-off-by: Maxime Ripard 

---

Changes in v4:
- Reworded the line length check comment
- Switch to HZ_PER_KHZ in tests
- Use previous timing to fill our mode
- Move the number of lines check earlier
---
 drivers/gpu/drm/drm_modes.c| 474 +
 drivers/gpu/drm/tests/Makefile |   1 +
 drivers/gpu/drm/tests/drm_modes_test.c | 144 ++
 include/drm/drm_modes.h|  17 ++
 4 files changed, 636 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 304004fb80aa..7cf2fe98d7d2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -116,6 +116,480 @@ void drm_mode_probed_add(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_probed_add);
 
+enum drm_mode_analog {
+   DRM_MODE_ANALOG_NTSC, /* 525 lines, 60Hz */
+   DRM_MODE_ANALOG_PAL, /* 625 lines, 50Hz */
+};
+
+/*
+ * The timings come from:
+ * - 
https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
+ * - 
https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
+ * - 
https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
+ */
+#define NTSC_LINE_DURATION_NS  63556U
+#define NTSC_LINES_NUMBER  525
+
+#define NTSC_HBLK_DURATION_TYP_NS  10900U
+#define NTSC_HBLK_DURATION_MIN_NS  (NTSC_HBLK_DURATION_TYP_NS - 200)
+#define NTSC_HBLK_DURATION_MAX_NS  (NTSC_HBLK_DURATION_TYP_NS + 200)
+
+#define NTSC_HACT_DURATION_TYP_NS  (NTSC_LINE_DURATION_NS - 
NTSC_HBLK_DURATION_TYP_NS)
+#define NTSC_HACT_DURATION_MIN_NS  (NTSC_LINE_DURATION_NS - 
NTSC_HBLK_DURATION_MAX_NS)
+#define NTSC_HACT_DURATION_MAX_NS  (NTSC_LINE_DURATION_NS - 
NTSC_HBLK_DURATION_MIN_NS)
+
+#define NTSC_HFP_DURATION_TYP_NS   1500
+#define NTSC_HFP_DURATION_MIN_NS   1270
+#define NTSC_HFP_DURATION_MAX_NS   2220
+
+#define NTSC_HSLEN_DURATION_TYP_NS 4700
+#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
+#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
+
+#define NTSC_HBP_DURATION_TYP_NS   4700
+
+/*
+ * I couldn't find the actual tolerance for the back porch, so let's
+ * just reuse the sync length ones.
+ */
+#define NTSC_HBP_DURATION_MIN_NS   (NTSC_HBP_DURATION_TYP_NS - 100)
+#define NTSC_HBP_DURATION_MAX_NS   (NTSC_HBP_DURATION_TYP_NS + 100)
+
+#define PAL_LINE_DURATION_NS   64000U
+#define PAL_LINES_NUMBER   625
+
+#define PAL_HACT_DURATION_TYP_NS   51950U
+#define PAL_HACT_DURATION_MIN_NS   (PAL_HACT_DURATION_TYP_NS - 100)
+#define PAL_HACT_DURATION_MAX_NS   (PAL_HACT_DURATION_TYP_NS + 400)
+
+#define PAL_HBLK_DURATION_TYP_NS   (PAL_LINE_DURATION_NS - 
PAL_HACT_DURATION_TYP_NS)
+#define PAL_HBLK_DURATION_MIN_NS   (PAL_LINE_DURATION_NS - 
PAL_HACT_DURATION_MAX_NS)
+#define PAL_HBLK_DURATION_MAX_NS   (PAL_LINE_DURATION_NS - 
PAL_HACT_DURATION_MIN_NS)
+
+#define PAL_HFP_DURATION_TYP_NS1650
+#define PAL_HFP_DURATION_MIN_NS(PAL_HFP_DURATION_TYP_NS - 100)
+#define PAL_HFP_DURATION_MAX_NS(PAL_HFP_DURATION_TYP_NS + 400)
+
+#define PAL_HSLEN_DURATION_TYP_NS  4700
+#define PAL_HSLEN_DURATION_MIN_NS  (PAL_HSLEN_DURATION_TYP_NS - 200)
+#define PAL_HSLEN_DURATION_MAX_NS  (PAL_HSLEN_DURATION_TYP_NS + 200)
+
+#define PAL_HBP_DURATION_TYP_NS5700
+#define PAL_HBP_DURATION_MIN_NS(PAL_HBP_DURATION_TYP_NS - 200)
+#define PAL_HBP_DURATION_MAX_NS(PAL_HBP_DURATION_TYP_NS + 200)
+
+struct analog_param_field {
+   unsigned int even, odd;
+};
+
+#define PARAM_FIELD(_odd, _even)   \
+   { .even = _even, .odd = _odd }
+
+struct analog_param_range {
+   unsigned intmin, typ, max;
+};
+
+#define PARAM_RANGE(_min, _typ, _max)  \
+   { .min = _min, .typ = _typ, .max = _max }
+
+struct analog_parameters {
+   unsigned intnum_lines;
+   unsigned intline_duration_ns;
+
+   struct analog_param_range   hact_ns;
+   struct analog_param_range   hfp_ns;
+   struct analog_param_range   hslen_ns;
+   struct analog_param_range   hbp_ns;
+   struct analog_param_range   hblk_ns;
+
+   unsigned intbt601_hfp;
+
+   struct analog_param_field  

[Intel-gfx] [PATCH v4 09/30] drm/connector: Rename drm_mode_create_tv_properties

[Maxime Ripard]

drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.

However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that function creating the property superseeding it in a later patch.

Reviewed-by: Lyude Paul  # nouveau
Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_connector.c   | 12 ++--
 drivers/gpu/drm/gud/gud_connector.c   |  4 ++--
 drivers/gpu/drm/i2c/ch7006_drv.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_tv.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |  2 +-
 drivers/gpu/drm/vc4/vc4_vec.c |  5 +++--
 include/drm/drm_connector.h   |  6 +++---
 7 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 17a5913cefe3..4e4fbc9e0049 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1600,7 +1600,7 @@ EXPORT_SYMBOL(drm_connector_attach_tv_margin_properties);
  * Called by a driver's HDMI connector initialization routine, this function
  * creates the TV margin properties for a given device. No need to call this
  * function for an SDTV connector, it's already called from
- * drm_mode_create_tv_properties().
+ * drm_mode_create_tv_properties_legacy().
  *
  * Returns:
  * 0 on success or a negative error code on failure.
@@ -1635,7 +1635,7 @@ int drm_mode_create_tv_margin_properties(struct 
drm_device *dev)
 EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
 
 /**
- * drm_mode_create_tv_properties - create TV specific connector properties
+ * drm_mode_create_tv_properties_legacy - create TV specific connector 
properties
  * @dev: DRM device
  * @num_modes: number of different TV formats (modes) supported
  * @modes: array of pointers to strings containing name of each format
@@ -1648,9 +1648,9 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
  * Returns:
  * 0 on success or a negative error code on failure.
  */
-int drm_mode_create_tv_properties(struct drm_device *dev,
- unsigned int num_modes,
- const char * const modes[])
+int drm_mode_create_tv_properties_legacy(struct drm_device *dev,
+unsigned int num_modes,
+const char * const modes[])
 {
struct drm_property *tv_selector;
struct drm_property *tv_subconnector;
@@ -1733,7 +1733,7 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 nomem:
return -ENOMEM;
 }
-EXPORT_SYMBOL(drm_mode_create_tv_properties);
+EXPORT_SYMBOL(drm_mode_create_tv_properties_legacy);
 
 /**
  * drm_mode_create_scaling_mode_property - create scaling mode property
diff --git a/drivers/gpu/drm/gud/gud_connector.c 
b/drivers/gpu/drm/gud/gud_connector.c
index 86e992b2108b..034e78360d4f 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -400,7 +400,7 @@ static int gud_connector_add_tv_mode(struct gud_device 
*gdrm, struct drm_connect
for (i = 0; i < num_modes; i++)
modes[i] = &buf[i * GUD_CONNECTOR_TV_MODE_NAME_LEN];
 
-   ret = drm_mode_create_tv_properties(connector->dev, num_modes, modes);
+   ret = drm_mode_create_tv_properties_legacy(connector->dev, num_modes, 
modes);
 free:
kfree(buf);
if (ret < 0)
@@ -539,7 +539,7 @@ static int gud_connector_add_properties(struct gud_device 
*gdrm, struct gud_conn
fallthrough;
case GUD_PROPERTY_TV_HUE:
/* This is a no-op if already added. */
-   ret = drm_mode_create_tv_properties(drm, 0, NULL);
+   ret = drm_mode_create_tv_properties_legacy(drm, 0, 
NULL);
if (ret)
goto out;
break;
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d29b63fd6178..506f6f932518 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -250,7 +250,7 @@ static int ch7006_encoder_create_resources(struct 
drm_encoder *encoder,
struct drm_device *dev = encoder->dev;
struct drm_mode_config *conf = &dev->mode_config;
 
-   drm_mode_create_tv_properties(dev, NUM_TV_NORMS, ch7006_tv_norm_names);
+   drm_mode_create_tv_properties_legacy(dev, NUM_TV_NORMS, 
ch7006_tv_norm_names);
 
priv->scale_property = drm_property_create_range(dev, 0, "scale", 0, 2);
if (!priv->scale_property)
diff --git a/drivers/gpu/drm/i915/display/intel_tv.c 
b/drivers/gpu/drm/i915/display/intel_tv.c
index abaf9ded942d..5e88da8185ee 100644
--- a/drivers/gpu/drm/i915/display/intel_tv.c
+++ b/drivers/gpu/drm/i915/display/intel_tv.c
@@ -1984,7 +1984,7 @@ in

[Intel-gfx] [PATCH v4 10/30] drm/connector: Add TV standard property

[Maxime Ripard]

The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.

Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and user-space.

Let's create a new enum tv norm property, that can contain any of the
analog TV standards currently supported by kernel drivers. Each driver can
then pass in a bitmask of the modes it supports, and the property
creation function will filter out the modes not supported.

We'll then be able to phase out the older tv mode property.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Add property documentation to kms-properties.csv
- Fix documentation
---
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c|  4 +++
 drivers/gpu/drm/drm_connector.c  | 57 +++-
 include/drm/drm_connector.h  | 64 
 include/drm/drm_mode_config.h|  8 +
 5 files changed, 133 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 45c12e3e82f4..3498bd5d5856 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -91,6 +91,7 @@ omap,Generic,“zorder”,RANGE,"Min=0, Max=3","CRTC, Plane",TBD
 qxl,Generic,"“hotplug_mode_update""",RANGE,"Min=0, Max=1",Connector,TBD
 radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
 ,DAC enable load detect,“load detection”,RANGE,"Min=0, Max=1",Connector,TBD
+,TV Mode,"""TV Mode""",ENUM,"{ ""NTSC"", ""NTSC-443"", ""NTSC-J"", ""PAL"", 
""PAL-M"", ""PAL-N"", ""SECAM"" }",Connector,TBD
 ,legacy TMDS PLL detect,"""tmds_pll""",ENUM,"{ ""driver"", ""bios"" }",-,TBD
 ,Underscan,"""underscan""",ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
 ,,"""underscan hborder""",RANGE,"Min=0, Max=128",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 7f2b9a07fbdf..d867e7f9f2cd 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->tv.margins.bottom = val;
} else if (property == config->legacy_tv_mode_property) {
state->tv.legacy_mode = val;
+   } else if (property == config->tv_mode_property) {
+   state->tv.mode = val;
} else if (property == config->tv_brightness_property) {
state->tv.brightness = val;
} else if (property == config->tv_contrast_property) {
@@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->tv.margins.bottom;
} else if (property == config->legacy_tv_mode_property) {
*val = state->tv.legacy_mode;
+   } else if (property == config->tv_mode_property) {
+   *val = state->tv.mode;
} else if (property == config->tv_brightness_property) {
*val = state->tv.brightness;
} else if (property == config->tv_contrast_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4e4fbc9e0049..8edc347ef664 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -980,6 +980,17 @@ static const struct drm_prop_enum_list 
drm_dvi_i_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
 drm_dvi_i_subconnector_enum_list)
 
+static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = {
+   { DRM_MODE_TV_MODE_NTSC, "NTSC" },
+   { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
+   { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
+   { DRM_MODE_TV_MODE_PAL, "PAL" },
+   { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
+   { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
+   { DRM_MODE_TV_MODE_SECAM, "SECAM" },
+};
+DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
+
 static const struct drm_prop_enum_list drm_tv_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
@@ -1645,6 +1656,10 @@ EXPORT_SYMBOL(drm_mode_create_tv_margin_properties);
  * responsible for allocating a list of format names and passing them to
  * this routine.
  *
+ * NOTE: This functions registers the deprecated "mode" connector
+ * property to select the analog TV mode (ie, NTSC, PAL, etc.). New
+ * drivers must use drm_mode_create_tv_properties() instead.
+ *
  * Returns:
  * 0 on success or a negative error code on failure.
  */
@@ -1686,7 +1701,6 @@ int drm_mode_create_tv_properties_legacy(struct 
drm_device *dev,
if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
 
-
if (num_modes) {
dev->mode_config.legacy_tv_mode_property

[Intel-gfx] [PATCH v4 13/30] drm/modes: parse_cmdline: Add support for named modes containing dashes

[Maxime Ripard]

From: Geert Uytterhoeven 

It is fairly common for named video modes to contain dashes (e.g.
"tt-mid" on Atari, "dblntsc-ff" on Amiga).  Currently such mode names
are not recognized, as the dash is considered to be a separator between
mode name and bpp.

Fix this by skipping any dashes that are not followed immediately by a
digit when looking for the separator.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Hans de Goede 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 99809ea09ce3..c0dceff51cac 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2284,6 +2284,8 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
 
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strnchr(name, options_off, '-');
+   while (bpp_ptr && !isdigit(bpp_ptr[1]))
+   bpp_ptr = strnchr(bpp_ptr + 1, options_off, '-');
if (bpp_ptr)
bpp_off = bpp_ptr - name;
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 18/30] drm/connector: Add pixel clock to cmdline mode

[Maxime Ripard]

We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 9 ++---
 include/drm/drm_connector.h | 7 +++
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 99453aca9a83..068c78d54db2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2226,22 +2226,24 @@ static int drm_mode_parse_cmdline_options(const char 
*str,
 
 struct drm_named_mode {
const char *name;
+   unsigned int pixel_clock_khz;
unsigned int xres;
unsigned int yres;
unsigned int flags;
 };
 
-#define NAMED_MODE(_name, _x, _y, _flags)  \
+#define NAMED_MODE(_name, _pclk, _x, _y, _flags)   \
{   \
.name = _name,  \
+   .pixel_clock_khz = _pclk,   \
.xres = _x, \
.yres = _y, \
.flags = _flags,\
}
 
 static const struct drm_named_mode drm_named_modes[] = {
-   NAMED_MODE("NTSC", 720, 480, DRM_MODE_FLAG_INTERLACE),
-   NAMED_MODE("PAL", 720, 576, DRM_MODE_FLAG_INTERLACE),
+   NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE),
+   NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE),
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2286,6 +2288,7 @@ static int drm_mode_parse_cmdline_named_mode(const char 
*name,
continue;
 
strcpy(cmdline_mode->name, mode->name);
+   cmdline_mode->pixel_clock = mode->pixel_clock_khz;
cmdline_mode->xres = mode->xres;
cmdline_mode->yres = mode->yres;
cmdline_mode->interlace = !!(mode->flags & 
DRM_MODE_FLAG_INTERLACE);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ef5f1c779de3..a501db7d 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1273,6 +1273,13 @@ struct drm_cmdline_mode {
 */
bool bpp_specified;
 
+   /**
+* @pixel_clock:
+*
+* Pixel Clock in kHz. Optional.
+*/
+   unsigned int pixel_clock;
+
/**
 * @xres:
 *

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 15/30] drm/modes: Move named modes parsing to a separate function

[Maxime Ripard]

The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.

In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Fold down all the named mode patches that were split into a single
  patch again to maintain bisectability
---
 drivers/gpu/drm/drm_modes.c | 73 ++---
 1 file changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c0dceff51cac..2f020ef2ddf2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2229,6 +2229,55 @@ static const char * const drm_named_modes_whitelist[] = {
"PAL",
 };
 
+static int drm_mode_parse_cmdline_named_mode(const char *name,
+unsigned int name_end,
+struct drm_cmdline_mode 
*cmdline_mode)
+{
+   unsigned int i;
+
+   if (!name_end)
+   return 0;
+
+   /* If the name starts with a digit, it's not a named mode */
+   if (isdigit(name[0]))
+   return 0;
+
+   /*
+* If there's an equal sign in the name, the command-line
+* contains only an option and no mode.
+*/
+   if (strnchr(name, name_end, '='))
+   return 0;
+
+#define STR_STRICT_EQ(str, len, cmp) \
+   (str_has_prefix(str, cmp) == len)
+
+   /* The connection status extras can be set without a mode. */
+   if (STR_STRICT_EQ(name, name_end, "d") ||
+   STR_STRICT_EQ(name, name_end, "D") ||
+   STR_STRICT_EQ(name, name_end, "e"))
+   return 0;
+
+   /*
+* We're sure we're a named mode at that point, iterate over the
+* list of modes we're aware of.
+*/
+   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+   int ret;
+
+   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+   if (ret != name_end)
+   continue;
+
+   strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
+   cmdline_mode->specified = true;
+
+   return 1;
+   }
+
+   return -EINVAL;
+}
+
 /**
  * drm_mode_parse_command_line_for_connector - parse command line modeline for 
connector
  * @mode_option: optional per connector mode option
@@ -2265,7 +2314,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
const char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
-   int i, len, ret;
+   int len, ret;
 
memset(mode, 0, sizeof(*mode));
mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
@@ -2306,17 +2355,19 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
parse_extras = true;
}
 
-   /* First check for a named mode */
-   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
-   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
-   if (ret == mode_end) {
-   if (refresh_ptr)
-   return false; /* named + refresh is invalid */
 
-   strcpy(mode->name, drm_named_modes_whitelist[i]);
-   mode->specified = true;
-   break;
-   }
+   if (mode_end) {
+   ret = drm_mode_parse_cmdline_named_mode(name, mode_end, mode);
+   if (ret < 0)
+   return false;
+
+   /*
+* Having a mode that starts by a letter (and thus is named)
+* and an at-sign (used to specify a refresh rate) is
+* disallowed.
+*/
+   if (ret && refresh_ptr)
+   return false;
}
 
/* No named mode? Check for a normal mode argument, e.g. 1024x768 */

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 16/30] drm/modes: Switch to named mode descriptors

[Maxime Ripard]

The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.

Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 2f020ef2ddf2..7ed3fb839db7 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2224,9 +2224,13 @@ static int drm_mode_parse_cmdline_options(const char 
*str,
return 0;
 }
 
-static const char * const drm_named_modes_whitelist[] = {
-   "NTSC",
-   "PAL",
+struct drm_named_mode {
+   const char *name;
+};
+
+static const struct drm_named_mode drm_named_modes[] = {
+   { "NTSC", },
+   { "PAL", },
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2262,14 +2266,15 @@ static int drm_mode_parse_cmdline_named_mode(const char 
*name,
 * We're sure we're a named mode at that point, iterate over the
 * list of modes we're aware of.
 */
-   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
+   for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
+   const struct drm_named_mode *mode = &drm_named_modes[i];
int ret;
 
-   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
+   ret = str_has_prefix(name, mode->name);
if (ret != name_end)
continue;
 
-   strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
+   strcpy(cmdline_mode->name, mode->name);
cmdline_mode->specified = true;
 
return 1;

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 25/30] drm/vc4: vec: Fix definition of PAL-M mode

[Maxime Ripard]

From: Mateusz Kwiatkowski 

PAL-M is a Brazilian analog TV standard that uses a PAL-style chroma
subcarrier at 3.575611[888111] MHz on top of 525-line (480i60) timings.
This commit makes the driver actually use the proper VEC preset for this
mode instead of just changing PAL subcarrier frequency.

Acked-by: Noralf Trønnes 
Signed-off-by: Mateusz Kwiatkowski 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_vec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 4d82ad30449b..adc9bf99e3fd 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -69,6 +69,7 @@
 #define VEC_CONFIG0_STD_MASK   GENMASK(1, 0)
 #define VEC_CONFIG0_NTSC_STD   0
 #define VEC_CONFIG0_PAL_BDGHI_STD  1
+#define VEC_CONFIG0_PAL_M_STD  2
 #define VEC_CONFIG0_PAL_N_STD  3
 
 #define VEC_SCHPH  0x108
@@ -255,10 +256,9 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
[VC4_VEC_TV_MODE_PAL_M] = {
-   .mode = &pal_mode,
-   .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
-   .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
-   .custom_freq = 0x223b61d1,
+   .mode = &ntsc_mode,
+   .config0 = VEC_CONFIG0_PAL_M_STD,
+   .config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
 };
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 26/30] drm/vc4: vec: Use TV Reset implementation

[Maxime Ripard]

The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().

Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index adc9bf99e3fd..90e375a8a8f9 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -268,6 +268,12 @@ vc4_vec_connector_detect(struct drm_connector *connector, 
bool force)
return connector_status_unknown;
 }
 
+static void vc4_vec_connector_reset(struct drm_connector *connector)
+{
+   drm_atomic_helper_connector_reset(connector);
+   drm_atomic_helper_connector_tv_reset(connector);
+}
+
 static int vc4_vec_connector_get_modes(struct drm_connector *connector)
 {
struct drm_connector_state *state = connector->state;
@@ -288,7 +294,7 @@ static int vc4_vec_connector_get_modes(struct drm_connector 
*connector)
 static const struct drm_connector_funcs vc4_vec_connector_funcs = {
.detect = vc4_vec_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
-   .reset = drm_atomic_helper_connector_reset,
+   .reset = vc4_vec_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 19/30] drm/connector: Add a function to lookup a TV mode by its name

[Maxime Ripard]

As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.

In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its value.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_connector.c | 24 
 include/drm/drm_connector.h |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8edc347ef664..ead5b30c193c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -991,6 +991,30 @@ static const struct drm_prop_enum_list 
drm_tv_mode_enum_list[] = {
 };
 DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
 
+/**
+ * drm_get_tv_mode_from_name - Translates a TV mode name into its enum value
+ * @name: TV Mode name we want to convert
+ * @len: Length of @name
+ *
+ * Translates @name into an enum drm_connector_tv_mode.
+ *
+ * Returns: the enum value on success, a negative errno otherwise.
+ */
+int drm_get_tv_mode_from_name(const char *name, size_t len)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(drm_tv_mode_enum_list); i++) {
+   const struct drm_prop_enum_list *item = 
&drm_tv_mode_enum_list[i];
+
+   if (strlen(item->name) == len && !strncmp(item->name, name, 
len))
+   return item->type;
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_get_tv_mode_from_name);
+
 static const struct drm_prop_enum_list drm_tv_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index a501db7d..a33f24a76738 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1864,6 +1864,8 @@ const char *drm_get_dp_subconnector_name(int val);
 const char *drm_get_content_protection_name(int val);
 const char *drm_get_hdcp_content_type_name(int val);
 
+int drm_get_tv_mode_from_name(const char *name, size_t len);
+
 int drm_mode_create_dvi_i_properties(struct drm_device *dev);
 void drm_connector_attach_dp_subconnector_property(struct drm_connector 
*connector);
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 28/30] drm/vc4: vec: Convert to the new TV mode property

[Maxime Ripard]

Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.

We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV atomic_check helper to make sure we trigger a modeset
whenever the TV mode is updated.

Acked-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Removed the count variable in .get_modes
---
 drivers/gpu/drm/vc4/vc4_vec.c | 192 +++---
 1 file changed, 144 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 1fcb7baf874e..b342dc9cf69c 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -172,6 +172,8 @@ struct vc4_vec {
 
struct clk *clock;
 
+   struct drm_property *legacy_tv_mode_property;
+
struct debugfs_regset32 regset;
 };
 
@@ -184,6 +186,12 @@ encoder_to_vc4_vec(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_vec, encoder.base);
 }
 
+static inline struct vc4_vec *
+connector_to_vc4_vec(struct drm_connector *connector)
+{
+   return container_of(connector, struct vc4_vec, connector);
+}
+
 enum vc4_vec_tv_mode_id {
VC4_VEC_TV_MODE_NTSC,
VC4_VEC_TV_MODE_NTSC_J,
@@ -192,7 +200,7 @@ enum vc4_vec_tv_mode_id {
 };
 
 struct vc4_vec_tv_mode {
-   const struct drm_display_mode *mode;
+   unsigned int mode;
u32 config0;
u32 config1;
u32 custom_freq;
@@ -225,43 +233,51 @@ static const struct debugfs_reg32 vec_regs[] = {
VC4_REG32(VEC_DAC_MISC),
 };
 
-static const struct drm_display_mode ntsc_mode = {
-   DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 13500,
-720, 720 + 14, 720 + 14 + 64, 720 + 14 + 64 + 60, 0,
-480, 480 + 7, 480 + 7 + 6, 525, 0,
-DRM_MODE_FLAG_INTERLACE)
-};
-
-static const struct drm_display_mode pal_mode = {
-   DRM_MODE("720x576", DRM_MODE_TYPE_DRIVER, 13500,
-720, 720 + 20, 720 + 20 + 64, 720 + 20 + 64 + 60, 0,
-576, 576 + 4, 576 + 4 + 6, 625, 0,
-DRM_MODE_FLAG_INTERLACE)
-};
-
 static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
-   [VC4_VEC_TV_MODE_NTSC] = {
-   .mode = &ntsc_mode,
+   {
+   .mode = DRM_MODE_TV_MODE_NTSC,
.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
-   [VC4_VEC_TV_MODE_NTSC_J] = {
-   .mode = &ntsc_mode,
+   {
+   .mode = DRM_MODE_TV_MODE_NTSC_J,
.config0 = VEC_CONFIG0_NTSC_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
-   [VC4_VEC_TV_MODE_PAL] = {
-   .mode = &pal_mode,
+   {
+   .mode = DRM_MODE_TV_MODE_PAL,
.config0 = VEC_CONFIG0_PAL_BDGHI_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
-   [VC4_VEC_TV_MODE_PAL_M] = {
-   .mode = &ntsc_mode,
+   {
+   .mode = DRM_MODE_TV_MODE_PAL_M,
.config0 = VEC_CONFIG0_PAL_M_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
 };
 
+static inline const struct vc4_vec_tv_mode *
+vc4_vec_tv_mode_lookup(unsigned int mode)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(vc4_vec_tv_modes); i++) {
+   const struct vc4_vec_tv_mode *tv_mode = &vc4_vec_tv_modes[i];
+
+   if (tv_mode->mode == mode)
+   return tv_mode;
+   }
+
+   return NULL;
+}
+
+static const struct drm_prop_enum_list tv_mode_names[] = {
+   { VC4_VEC_TV_MODE_NTSC, "NTSC", },
+   { VC4_VEC_TV_MODE_NTSC_J, "NTSC-J", },
+   { VC4_VEC_TV_MODE_PAL, "PAL", },
+   { VC4_VEC_TV_MODE_PAL_M, "PAL-M", },
+};
+
 static enum drm_connector_status
 vc4_vec_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -276,19 +292,96 @@ static void vc4_vec_connector_reset(struct drm_connector 
*connector)
 
 static int vc4_vec_connector_get_modes(struct drm_connector *connector)
 {
-   struct drm_connector_state *state = connector->state;
struct drm_display_mode *mode;
 
-   mode = drm_mode_duplicate(connector->dev,
- vc4_vec_tv_modes[state->tv.legacy_mode].mode);
+   mode = drm_mode_analog_ntsc_480i(connector->dev);
if (!mode) {
DRM_ERROR("Failed to create a new display mode\n");
return -ENOMEM;
}
 
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
 
-   return 1;
+   mode = drm_mode_analog_pal_576i(connector->dev);
+   if (!mode) {
+   DRM_ERROR("Failed to create a new display mode\n");
+   return -ENOMEM;
+   }
+
+   drm_mode_probed_add(connector, mode);
+
+   

[Intel-gfx] [PATCH v4 29/30] drm/vc4: vec: Add support for more analog TV standards

[Maxime Ripard]

From: Mateusz Kwiatkowski 

Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):

- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
  4.43361875 MHz (the PAL subcarrier frequency). Never used for
  broadcasting, but sometimes used as a hack to play NTSC content in PAL
  regions (e.g. on VCRs).
- PAL_N - PAL with alternative chroma subcarrier frequency,
  3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
  and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
- PAL60 - 480i60 signal with PAL-style color at normal European PAL
  frequency. Another non-standard, non-broadcast mode, used in similar
  contexts as NTSC_443. Some displays support one but not the other.
- SECAM - French frequency-modulated analog color standard; also have
  been broadcast in Eastern Europe and various parts of Africa and Asia.
  Uses the same 576i50 timings as PAL.

Also added some comments explaining color subcarrier frequency
registers.

Acked-by: Noralf Trønnes 
Signed-off-by: Mateusz Kwiatkowski 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_vec.c | 84 ++-
 1 file changed, 83 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index b342dc9cf69c..8d37d7ba9b2a 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -46,6 +46,7 @@
 #define VEC_CONFIG0_YDEL(x)((x) << 26)
 #define VEC_CONFIG0_CDEL_MASK  GENMASK(25, 24)
 #define VEC_CONFIG0_CDEL(x)((x) << 24)
+#define VEC_CONFIG0_SECAM_STD  BIT(21)
 #define VEC_CONFIG0_PBPR_FIL   BIT(18)
 #define VEC_CONFIG0_CHROMA_GAIN_MASK   GENMASK(17, 16)
 #define VEC_CONFIG0_CHROMA_GAIN_UNITY  (0 << 16)
@@ -76,6 +77,27 @@
 #define VEC_SOFT_RESET 0x10c
 #define VEC_CLMP0_START0x144
 #define VEC_CLMP0_END  0x148
+
+/*
+ * These set the color subcarrier frequency
+ * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
+ *
+ * VEC_FREQ1_0 contains the most significant 16-bit half-word,
+ * VEC_FREQ3_2 contains the least significant 16-bit half-word.
+ * 0x8000 seems to be equivalent to the pixel clock
+ * (which itself is the VEC clock divided by 8).
+ *
+ * Reference values (with the default pixel clock of 13.5 MHz):
+ *
+ * NTSC  (3579545.[45] Hz) - 0x21F07C1F
+ * PAL   (4433618.75 Hz)   - 0x2A098ACB
+ * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
+ * PAL-N (3582056.25 Hz)   - 0x21F69446
+ *
+ * NOTE: For SECAM, it is used as the Dr center frequency,
+ * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
+ * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
+ */
 #define VEC_FREQ3_20x180
 #define VEC_FREQ1_00x184
 
@@ -118,6 +140,14 @@
 
 #define VEC_INTERRUPT_CONTROL  0x190
 #define VEC_INTERRUPT_STATUS   0x194
+
+/*
+ * Db center frequency for SECAM; the clock for this is the same as for
+ * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
+ *
+ * This is specified as 425 Hz, which corresponds to 0x284BDA13.
+ * That is also the default value, so no need to set it explicitly.
+ */
 #define VEC_FCW_SECAM_B0x198
 #define VEC_SECAM_GAIN_VAL 0x19c
 
@@ -197,6 +227,10 @@ enum vc4_vec_tv_mode_id {
VC4_VEC_TV_MODE_NTSC_J,
VC4_VEC_TV_MODE_PAL,
VC4_VEC_TV_MODE_PAL_M,
+   VC4_VEC_TV_MODE_NTSC_443,
+   VC4_VEC_TV_MODE_PAL_60,
+   VC4_VEC_TV_MODE_PAL_N,
+   VC4_VEC_TV_MODE_SECAM,
 };
 
 struct vc4_vec_tv_mode {
@@ -239,6 +273,12 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
+   {
+   .mode = DRM_MODE_TV_MODE_NTSC_443,
+   .config0 = VEC_CONFIG0_NTSC_STD,
+   .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
+   .custom_freq = 0x2a098acb,
+   },
{
.mode = DRM_MODE_TV_MODE_NTSC_J,
.config0 = VEC_CONFIG0_NTSC_STD,
@@ -254,6 +294,17 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config0 = VEC_CONFIG0_PAL_M_STD,
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
},
+   {
+   .mode = DRM_MODE_TV_MODE_PAL_N,
+   .config0 = VEC_CONFIG0_PAL_N_STD,
+   .config1 = VEC_CONFIG1_C_CVBS_CVBS,
+   },
+   {
+   .mode = DRM_MODE_TV_MODE_SECAM,
+   .config0 = VEC_CONFIG0_SECAM_STD,
+   .config1 = VEC_CONFIG1_C_CVBS_CVBS,
+   .custom_freq = 0x29c71c72,
+   },
 };
 
 static inline const struct vc4_vec_tv_mode *
@@ -273,9 +324,13 @@ vc4_vec_tv_mode_lookup(unsigned int mode)
 
 static const struct drm_prop_enum_l

[Intel-gfx] [PATCH v4 20/30] drm/modes: Introduce the tv_mode property as a command-line option

[Maxime Ripard]

Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.

Let's add some code to allow it, and some unit tests to exercise that code.

Signed-off-by: Maxime Ripard 

---
Changes in v4:
- Add Documentation of the command-line option to modedb.rst
---
 Documentation/fb/modedb.rst |  2 +
 drivers/gpu/drm/drm_modes.c | 35 +++--
 drivers/gpu/drm/tests/drm_cmdline_parser_test.c | 67 +
 include/drm/drm_connector.h |  5 ++
 4 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
index 4d2411e32ebb..5d6361a77f3c 100644
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@ -65,6 +65,8 @@ Valid options are::
   - reflect_y (boolean): Perform an axial symmetry on the Y axis
   - rotate (integer): Rotate the initial framebuffer by x
 degrees. Valid values are 0, 90, 180 and 270.
+  - tv_mode: Analog TV mode. One of "NTSC", "NTSC-443", "NTSC-J", "PAL",
+"PAL-M", "PAL-N", or "SECAM".
   - panel_orientation, one of "normal", "upside_down", "left_side_up", or
 "right_side_up". For KMS drivers only, this sets the "panel orientation"
 property on the kms connector as hint for kms users.
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 068c78d54db2..c9b62e30e303 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2133,6 +2133,29 @@ static int drm_mode_parse_panel_orientation(const char 
*delim,
return 0;
 }
 
+static int drm_mode_parse_tv_mode(const char *delim,
+ struct drm_cmdline_mode *mode)
+{
+   const char *value;
+   int ret;
+
+   if (*delim != '=')
+   return -EINVAL;
+
+   value = delim + 1;
+   delim = strchr(value, ',');
+   if (!delim)
+   delim = value + strlen(value);
+
+   ret = drm_get_tv_mode_from_name(value, delim - value);
+   if (ret < 0)
+   return ret;
+
+   mode->tv_mode = ret;
+
+   return 0;
+}
+
 static int drm_mode_parse_cmdline_options(const char *str,
  bool freestanding,
  const struct drm_connector *connector,
@@ -2202,6 +2225,9 @@ static int drm_mode_parse_cmdline_options(const char *str,
} else if (!strncmp(option, "panel_orientation", delim - 
option)) {
if (drm_mode_parse_panel_orientation(delim, mode))
return -EINVAL;
+   } else if (!strncmp(option, "tv_mode", delim - option)) {
+   if (drm_mode_parse_tv_mode(delim, mode))
+   return -EINVAL;
} else {
return -EINVAL;
}
@@ -2230,20 +2256,22 @@ struct drm_named_mode {
unsigned int xres;
unsigned int yres;
unsigned int flags;
+   unsigned int tv_mode;
 };
 
-#define NAMED_MODE(_name, _pclk, _x, _y, _flags)   \
+#define NAMED_MODE(_name, _pclk, _x, _y, _flags, _mode)\
{   \
.name = _name,  \
.pixel_clock_khz = _pclk,   \
.xres = _x, \
.yres = _y, \
.flags = _flags,\
+   .tv_mode = _mode,   \
}
 
 static const struct drm_named_mode drm_named_modes[] = {
-   NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE),
-   NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE),
+   NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_NTSC),
+   NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_PAL),
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2292,6 +2320,7 @@ static int drm_mode_parse_cmdline_named_mode(const char 
*name,
cmdline_mode->xres = mode->xres;
cmdline_mode->yres = mode->yres;
cmdline_mode->interlace = !!(mode->flags & 
DRM_MODE_FLAG_INTERLACE);
+   cmdline_mode->tv_mode = mode->tv_mode;
cmdline_mode->specified = true;
 
return 1;
diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c 
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 34790e7a3760..3e711b83b823 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -927,6 +927,14 @@ static const struct drm_cmdline_invalid_test 
drm_cmdline_invalid_tests[] = {
.name = "invalid_option",
.cmdline = "7

[Intel-gfx] [PATCH v4 21/30] drm/modes: Properly generate a drm_display_mode from a named mode

[Maxime Ripard]

The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().

The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.

In the case of the named modes though, there's no real code to make that
translation and we rely on the drivers to guess which actual display mode
we meant.

Let's modify drm_mode_create_from_cmdline_mode() to properly generate the
drm_display_mode we mean when passing a named mode.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 34 +++-
 drivers/gpu/drm/tests/drm_client_modeset_test.c | 71 +
 2 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c9b62e30e303..fe818252cd8f 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2500,6 +2500,36 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 }
 EXPORT_SYMBOL(drm_mode_parse_command_line_for_connector);
 
+static struct drm_display_mode *drm_named_mode(struct drm_device *dev,
+  struct drm_cmdline_mode *cmd)
+{
+   struct drm_display_mode *mode;
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
+   const struct drm_named_mode *named_mode = &drm_named_modes[i];
+
+   if (strcmp(cmd->name, named_mode->name))
+   continue;
+
+   if (!named_mode->tv_mode)
+   continue;
+
+   mode = drm_analog_tv_mode(dev,
+ named_mode->tv_mode,
+ named_mode->pixel_clock_khz * 1000,
+ named_mode->xres,
+ named_mode->yres,
+ named_mode->flags & 
DRM_MODE_FLAG_INTERLACE);
+   if (!mode)
+   return NULL;
+
+   return mode;
+   }
+
+   return NULL;
+}
+
 /**
  * drm_mode_create_from_cmdline_mode - convert a command line modeline into a 
DRM display mode
  * @dev: DRM device to create the new mode for
@@ -2517,7 +2547,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
if (cmd->xres == 0 || cmd->yres == 0)
return NULL;
 
-   if (cmd->cvt)
+   if (strlen(cmd->name))
+   mode = drm_named_mode(dev, cmd);
+   else if (cmd->cvt)
mode = drm_cvt_mode(dev,
cmd->xres, cmd->yres,
cmd->refresh_specified ? cmd->refresh : 60,
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c 
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index 09dc5acbbc42..b59029b49201 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -26,6 +26,20 @@ static int drm_client_modeset_connector_get_modes(struct 
drm_connector *connecto
 
count = drm_add_modes_noedid(connector, 1920, 1200);
 
+   mode = drm_mode_analog_ntsc_480i(connector->dev);
+   if (!mode)
+   return -ENOMEM;
+
+   drm_mode_probed_add(connector, mode);
+   count += 1;
+
+   mode = drm_mode_analog_pal_576i(connector->dev);
+   if (!mode)
+   return -ENOMEM;
+
+   drm_mode_probed_add(connector, mode);
+   count += 1;
+
return count;
 }
 
@@ -58,6 +72,9 @@ static int drm_client_modeset_test_init(struct kunit *test)
return ret;
drm_connector_helper_add(&priv->connector, 
&drm_client_modeset_connector_helper_funcs);
 
+   priv->connector.interlace_allowed = true;
+   priv->connector.doublescan_allowed = true;
+
return 0;
 
 }
@@ -91,8 +108,62 @@ static void drm_pick_cmdline_res_1920_1080_60(struct kunit 
*test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
 }
 
+static void drm_pick_cmdline_named_ntsc(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct drm_connector *connector = &priv->connector;
+   struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+   struct drm_display_mode *mode;
+   const char *cmdline = "NTSC";
+   int ret;
+
+   KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+   connector,
+   
cmdline_mode));
+
+   mutex_lock(&drm->mode_config.mutex);
+   ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+   mutex_unlock(&drm->mode_config.mutex);
+   KUNIT_ASSERT_GT(test, ret, 0);
+
+   mode = drm_c

[Intel-gfx] [PATCH v4 23/30] drm/atomic-helper: Add a TV properties reset helper

[Maxime Ripard]

The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.

Let's create a helper that will take care of it.

Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic_state_helper.c | 75 +++
 include/drm/drm_atomic_state_helper.h |  1 +
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index dfb57217253b..0373c3dc824b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -481,6 +481,81 @@ void drm_atomic_helper_connector_tv_margins_reset(struct 
drm_connector *connecto
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
 
+/**
+ * drm_atomic_helper_connector_tv_reset - Resets Analog TV connector properties
+ * @connector: DRM connector
+ *
+ * Resets the analog TV properties attached to a connector
+ */
+void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
+   struct drm_connector_state *state = connector->state;
+   struct drm_property *prop;
+   uint64_t val;
+
+   prop = dev->mode_config.tv_mode_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.mode = val;
+
+   if (cmdline->tv_mode)
+   state->tv.mode = cmdline->tv_mode;
+
+   prop = dev->mode_config.tv_select_subconnector_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.select_subconnector = val;
+
+   prop = dev->mode_config.tv_subconnector_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.subconnector = val;
+
+   prop = dev->mode_config.tv_brightness_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.brightness = val;
+
+   prop = dev->mode_config.tv_contrast_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.contrast = val;
+
+   prop = dev->mode_config.tv_flicker_reduction_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.flicker_reduction = val;
+
+   prop = dev->mode_config.tv_overscan_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.overscan = val;
+
+   prop = dev->mode_config.tv_saturation_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.saturation = val;
+
+   prop = dev->mode_config.tv_hue_property;
+   if (prop)
+   if (!drm_object_property_get_default_value(&connector->base,
+  prop, &val))
+   state->tv.hue = val;
+
+   drm_atomic_helper_connector_tv_margins_reset(connector);
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
  * @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h 
b/include/drm/drm_atomic_state_helper.h
index 192766656b88..c8fbce795ee7 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -70,6 +70,7 @@ void __drm_atomic_helper_connector_state_reset(struct 
drm_connector_state *conn_
 void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
 struct drm_connector_state 
*conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
+void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
 void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector 
*connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct

[Intel-gfx] [PATCH v4 27/30] drm/vc4: vec: Check for VEC output constraints

[Maxime Ripard]

From: Mateusz Kwiatkowski 

The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.

Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.

Acked-by: Noralf Trønnes 
Signed-off-by: Mateusz Kwiatkowski 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_vec.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 90e375a8a8f9..1fcb7baf874e 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -453,6 +453,7 @@ static int vc4_vec_encoder_atomic_check(struct drm_encoder 
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
 {
+   const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
const struct vc4_vec_tv_mode *vec_mode;
 
vec_mode = &vc4_vec_tv_modes[conn_state->tv.legacy_mode];
@@ -461,6 +462,53 @@ static int vc4_vec_encoder_atomic_check(struct drm_encoder 
*encoder,
!drm_mode_equal(vec_mode->mode, &crtc_state->adjusted_mode))
return -EINVAL;
 
+   if (mode->crtc_hdisplay % 4)
+   return -EINVAL;
+
+   if (!(mode->crtc_hsync_end - mode->crtc_hsync_start))
+   return -EINVAL;
+
+   switch (mode->vtotal) {
+   case 525:
+   if (mode->crtc_vtotal > 262)
+   return -EINVAL;
+
+   if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 253)
+   return -EINVAL;
+
+   if (!(mode->crtc_vsync_start - mode->crtc_vdisplay))
+   return -EINVAL;
+
+   if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3)
+   return -EINVAL;
+
+   if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 4)
+   return -EINVAL;
+
+   break;
+
+   case 625:
+   if (mode->crtc_vtotal > 312)
+   return -EINVAL;
+
+   if (mode->crtc_vdisplay < 1 || mode->crtc_vdisplay > 305)
+   return -EINVAL;
+
+   if (!(mode->crtc_vsync_start - mode->crtc_vdisplay))
+   return -EINVAL;
+
+   if ((mode->crtc_vsync_end - mode->crtc_vsync_start) != 3)
+   return -EINVAL;
+
+   if ((mode->crtc_vtotal - mode->crtc_vsync_end) < 2)
+   return -EINVAL;
+
+   break;
+
+   default:
+   return -EINVAL;
+   }
+
return 0;
 }
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 30/30] drm/sun4i: tv: Convert to the new TV mode property

[Maxime Ripard]

Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tv.c | 148 ++-
 drivers/gpu/drm/vc4/vc4_vec.c|   5 +-
 2 files changed, 54 insertions(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index c65f0a89b6b0..1a8f5b986a95 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -141,23 +141,14 @@ struct resync_parameters {
 struct tv_mode {
char*name;
 
+   unsigned inttv_mode;
+
u32 mode;
u32 chroma_freq;
u16 back_porch;
u16 front_porch;
-   u16 line_number;
u16 vblank_level;
 
-   u32 hdisplay;
-   u16 hfront_porch;
-   u16 hsync_len;
-   u16 hback_porch;
-
-   u32 vdisplay;
-   u16 vfront_porch;
-   u16 vsync_len;
-   u16 vback_porch;
-
boolyc_en;
booldac3_en;
booldac_bit25_en;
@@ -213,7 +204,7 @@ static const struct resync_parameters pal_resync_parameters 
= {
 
 static const struct tv_mode tv_modes[] = {
{
-   .name   = "NTSC",
+   .tv_mode= DRM_MODE_TV_MODE_NTSC,
.mode   = SUN4I_TVE_CFG0_RES_480i,
.chroma_freq= 0x21f07c1f,
.yc_en  = true,
@@ -222,17 +213,6 @@ static const struct tv_mode tv_modes[] = {
 
.back_porch = 118,
.front_porch= 32,
-   .line_number= 525,
-
-   .hdisplay   = 720,
-   .hfront_porch   = 18,
-   .hsync_len  = 2,
-   .hback_porch= 118,
-
-   .vdisplay   = 480,
-   .vfront_porch   = 26,
-   .vsync_len  = 2,
-   .vback_porch= 17,
 
.vblank_level   = 240,
 
@@ -242,23 +222,12 @@ static const struct tv_mode tv_modes[] = {
.resync_params  = &ntsc_resync_parameters,
},
{
-   .name   = "PAL",
+   .tv_mode= DRM_MODE_TV_MODE_PAL,
.mode   = SUN4I_TVE_CFG0_RES_576i,
.chroma_freq= 0x2a098acb,
 
.back_porch = 138,
.front_porch= 24,
-   .line_number= 625,
-
-   .hdisplay   = 720,
-   .hfront_porch   = 3,
-   .hsync_len  = 2,
-   .hback_porch= 139,
-
-   .vdisplay   = 576,
-   .vfront_porch   = 28,
-   .vsync_len  = 2,
-   .vback_porch= 19,
 
.vblank_level   = 252,
 
@@ -276,63 +245,21 @@ drm_encoder_to_sun4i_tv(struct drm_encoder *encoder)
encoder);
 }
 
-/*
- * FIXME: If only the drm_display_mode private field was usable, this
- * could go away...
- *
- * So far, it doesn't seem to be preserved when the mode is passed by
- * to mode_set for some reason.
- */
-static const struct tv_mode *sun4i_tv_find_tv_by_mode(const struct 
drm_display_mode *mode)
+static const struct tv_mode *
+sun4i_tv_find_tv_by_mode(unsigned int mode)
 {
int i;
 
-   /* First try to identify the mode by name */
for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
const struct tv_mode *tv_mode = &tv_modes[i];
 
-   DRM_DEBUG_DRIVER("Comparing mode %s vs %s",
-mode->name, tv_mode->name);
-
-   if (!strcmp(mode->name, tv_mode->name))
-   return tv_mode;
-   }
-
-   /* Then by number of lines */
-   for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
-   const struct tv_mode *tv_mode = &tv_modes[i];
-
-   DRM_DEBUG_DRIVER("Comparing mode %s vs %s (X: %d vs %d)",
-mode->name, tv_mode->name,
-mode->vdisplay, tv_mode->vdisplay);
-
-   if (mode->vdisplay == tv_mode->vdisplay)
+   if (tv_mode->tv_mode == mode)
return tv_mode;
}
 
return NULL;
 }
 
-static void sun4i_tv_mode_to_drm_mode(const struct tv_mode *tv_mode,
- struct drm_display_mode *mode)
-{
-   DRM_DEBUG_DRIVER("Creating mode %s\n", mode->name);
-
-   mode->type = DRM_MODE_TYPE_DRIVER;
-   mode->clock = 13500;
-   mode->flags = DRM_MODE_FLAG_INTERLACE;
-
-   mode->hdisplay = tv_mode->hdisplay;
-   mode->hsync_start = mode->hdisplay + tv_mode->hfront_porch;
-   mode->hsync_end = mode->hsync_start + tv_mode->hsync_len;
-   mode->htotal = mode

[Intel-gfx] [PATCH v4 22/30] drm/modes: Introduce more named modes

[Maxime Ripard]

Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c |  2 +
 drivers/gpu/drm/tests/drm_client_modeset_test.c | 54 +
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fe818252cd8f..e3307662d6da 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2271,7 +2271,9 @@ struct drm_named_mode {
 
 static const struct drm_named_mode drm_named_modes[] = {
NAMED_MODE("NTSC", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_NTSC),
+   NAMED_MODE("NTSC-J", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_NTSC_J),
NAMED_MODE("PAL", 13500, 720, 576, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_PAL),
+   NAMED_MODE("PAL-M", 13500, 720, 480, DRM_MODE_FLAG_INTERLACE, 
DRM_MODE_TV_MODE_PAL_M),
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c 
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
index b59029b49201..b72433a0216a 100644
--- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -134,6 +134,32 @@ static void drm_pick_cmdline_named_ntsc(struct kunit *test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm), 
mode));
 }
 
+static void drm_pick_cmdline_named_ntsc_j(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct drm_connector *connector = &priv->connector;
+   struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+   struct drm_display_mode *mode;
+   const char *cmdline = "NTSC-J";
+   int ret;
+
+   KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+   connector,
+   
cmdline_mode));
+
+   mutex_lock(&drm->mode_config.mutex);
+   ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+   mutex_unlock(&drm->mode_config.mutex);
+   KUNIT_ASSERT_GT(test, ret, 0);
+
+   mode = drm_connector_pick_cmdline_mode(connector);
+   KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+   KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm), 
mode));
+}
+
 static void drm_pick_cmdline_named_pal(struct kunit *test)
 {
struct drm_client_modeset_test_priv *priv = test->priv;
@@ -160,10 +186,38 @@ static void drm_pick_cmdline_named_pal(struct kunit *test)
KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_pal_576i(drm), 
mode));
 }
 
+static void drm_pick_cmdline_named_pal_m(struct kunit *test)
+{
+   struct drm_client_modeset_test_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct drm_connector *connector = &priv->connector;
+   struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+   struct drm_display_mode *mode;
+   const char *cmdline = "PAL-M";
+   int ret;
+
+   KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+   connector,
+   
cmdline_mode));
+
+   mutex_lock(&drm->mode_config.mutex);
+   ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+   mutex_unlock(&drm->mode_config.mutex);
+   KUNIT_ASSERT_GT(test, ret, 0);
+
+   mode = drm_connector_pick_cmdline_mode(connector);
+   KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+   KUNIT_EXPECT_TRUE(test, drm_mode_equal(drm_mode_analog_ntsc_480i(drm), 
mode));
+}
+
 static struct kunit_case drm_pick_cmdline_tests[] = {
KUNIT_CASE(drm_pick_cmdline_res_1920_1080_60),
KUNIT_CASE(drm_pick_cmdline_named_ntsc),
+   KUNIT_CASE(drm_pick_cmdline_named_ntsc_j),
KUNIT_CASE(drm_pick_cmdline_named_pal),
+   KUNIT_CASE(drm_pick_cmdline_named_pal_m),
{}
 };
 

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 24/30] drm/atomic-helper: Add an analog TV atomic_check implementation

[Maxime Ripard]

The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.

Let's create an atomic_check helper for those use cases.

Reviewed-by: Noralf Trønnes 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_atomic_state_helper.c | 49 +++
 include/drm/drm_atomic_state_helper.h |  3 ++
 2 files changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 0373c3dc824b..e88c57a4f7be 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -556,6 +556,55 @@ void drm_atomic_helper_connector_tv_reset(struct 
drm_connector *connector)
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
 
+/**
+ * @drm_atomic_helper_connector_tv_check: Validate an analog TV connector state
+ * @connector: DRM Connector
+ * @state: the DRM State object
+ *
+ * Checks the state object to see if the requested state is valid for an
+ * analog TV connector.
+ *
+ * Returns:
+ * Zero for success, a negative error code on error.
+ */
+int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
+struct drm_atomic_state *state)
+{
+   struct drm_connector_state *old_conn_state =
+   drm_atomic_get_old_connector_state(state, connector);
+   struct drm_connector_state *new_conn_state =
+   drm_atomic_get_new_connector_state(state, connector);
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+
+   crtc = new_conn_state->crtc;
+   if (!crtc)
+   return 0;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (!crtc_state)
+   return -EINVAL;
+
+   if (old_conn_state->tv.mode != new_conn_state->tv.mode)
+   crtc_state->mode_changed = true;
+
+   if ((old_conn_state->tv.margins.left != 
new_conn_state->tv.margins.left) ||
+   (old_conn_state->tv.margins.right != 
new_conn_state->tv.margins.right) ||
+   (old_conn_state->tv.margins.top != new_conn_state->tv.margins.top) 
||
+   (old_conn_state->tv.margins.bottom != 
new_conn_state->tv.margins.bottom) ||
+   (old_conn_state->tv.mode != new_conn_state->tv.mode) ||
+   (old_conn_state->tv.brightness != new_conn_state->tv.brightness) ||
+   (old_conn_state->tv.contrast != new_conn_state->tv.contrast) ||
+   (old_conn_state->tv.flicker_reduction != 
new_conn_state->tv.flicker_reduction) ||
+   (old_conn_state->tv.overscan != new_conn_state->tv.overscan) ||
+   (old_conn_state->tv.saturation != new_conn_state->tv.saturation) ||
+   (old_conn_state->tv.hue != new_conn_state->tv.hue))
+   crtc_state->connectors_changed = true;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_check);
+
 /**
  * __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
  * @connector: connector object
diff --git a/include/drm/drm_atomic_state_helper.h 
b/include/drm/drm_atomic_state_helper.h
index c8fbce795ee7..b9740edb2658 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -26,6 +26,7 @@
 
 #include 
 
+struct drm_atomic_state;
 struct drm_bridge;
 struct drm_bridge_state;
 struct drm_crtc;
@@ -71,6 +72,8 @@ void __drm_atomic_helper_connector_reset(struct drm_connector 
*connector,
 struct drm_connector_state 
*conn_state);
 void drm_atomic_helper_connector_reset(struct drm_connector *connector);
 void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
+struct drm_atomic_state *state);
 void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector 
*connector);
 void
 __drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,

-- 
b4 0.11.0-dev-7da52

[Intel-gfx] [PATCH v4 17/30] drm/modes: Fill drm_cmdline mode from named modes

[Maxime Ripard]

The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.

The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes and properties. Let's
start by properly filling drm_cmdline_mode from a named mode.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 7ed3fb839db7..99453aca9a83 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2226,11 +2226,22 @@ static int drm_mode_parse_cmdline_options(const char 
*str,
 
 struct drm_named_mode {
const char *name;
+   unsigned int xres;
+   unsigned int yres;
+   unsigned int flags;
 };
 
+#define NAMED_MODE(_name, _x, _y, _flags)  \
+   {   \
+   .name = _name,  \
+   .xres = _x, \
+   .yres = _y, \
+   .flags = _flags,\
+   }
+
 static const struct drm_named_mode drm_named_modes[] = {
-   { "NTSC", },
-   { "PAL", },
+   NAMED_MODE("NTSC", 720, 480, DRM_MODE_FLAG_INTERLACE),
+   NAMED_MODE("PAL", 720, 576, DRM_MODE_FLAG_INTERLACE),
 };
 
 static int drm_mode_parse_cmdline_named_mode(const char *name,
@@ -2275,6 +2286,9 @@ static int drm_mode_parse_cmdline_named_mode(const char 
*name,
continue;
 
strcpy(cmdline_mode->name, mode->name);
+   cmdline_mode->xres = mode->xres;
+   cmdline_mode->yres = mode->yres;
+   cmdline_mode->interlace = !!(mode->flags & 
DRM_MODE_FLAG_INTERLACE);
cmdline_mode->specified = true;
 
return 1;

-- 
b4 0.11.0-dev-7da52

Re: [Intel-gfx] [PATCH 05/16] drm/i915/vm_bind: Implement bind and unbind of object

[Niranjana Vishwanathapura]

On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:

On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:

Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.

The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be supported only in the newer execbuf3 ioctl.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   5 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  26 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 306 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  17 +
 drivers/gpu/drm/i915/i915_driver.c|   3 +
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 112 +++
 10 files changed, 495 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..9bf939ef18ea 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ gem-y += \
gem/i915_gem_ttm_move.o \
gem/i915_gem_ttm_pm.o \
gem/i915_gem_userptr.o \
+   gem/i915_gem_vm_bind_object.o \
gem/i915_gem_wait.o \
gem/i915_gemfs.o
 i915-y += \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cd75b0ca2555..f85f10cf9c34 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -781,6 +781,11 @@ static int eb_select_context(struct i915_execbuffer *eb)
if (unlikely(IS_ERR(ctx)))
return PTR_ERR(ctx);
+   if (ctx->vm->vm_bind_mode) {
+   i915_gem_context_put(ctx);
+   return -EOPNOTSUPP;
+   }
+
eb->gem_context = ctx;
if (i915_gem_context_has_full_ppgtt(ctx))
eb->invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
new file mode 100644
index ..36262a6357b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_VM_BIND_H
+#define __I915_GEM_VM_BIND_H
+
+#include 
+
+struct drm_device;
+struct drm_file;
+struct i915_address_space;
+struct i915_vma;
+
+struct i915_vma *
+i915_gem_vm_bind_lookup_vma(struct i915_address_space *vm, u64 va);
+
+int i915_gem_vm_bind_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
+int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file);
+
+void i915_gem_vm_unbind_all(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_VM_BIND_H */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
new file mode 100644
index ..e529162abd2c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_vm_bind.h"
+
+#include "gt/intel_gpu_commands.h"
+
+#define START(node) ((node)->start)
+#define LAST(node) ((node)->last)
+
+INTERVAL_TREE_DEFINE(struct i915_vma, rb, u64, __subtree_last,
+START, LAST, static inline, i915_vm_bind_it)
+
+#undef START
+#undef LAST
+
+/**
+ * DOC: VM_BIND/UNBIND ioctls
+ *
+ * DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer
+ * objects (BOs) or sections of a BOs at specified GPU virtual addresses on a
+ * specified address space (VM). Multiple mappings can map to the same physical
+ * pages of an object (aliasing). These mappings (also referred to as 
persistent
+ * mappings) will be persistent across multiple GPU submissions (execbuf calls)
+ * issued by the UMD, without user having to provide a list of all required
+ * mappings during each submission (as required by older execbuf mode).
+ *
+ * The VM_BIND/UNBIND calls allow UMDs to request a timeline out fence for
+ * signaling the completion of bind/unbind operation.
+ *
+ * VM_BIND feature is advertised to user via I915_PARAM_VM_BIND_VERSION.
+ * User has to opt-in for VM_BIND mode of binding for an address space (VM)
+ * during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension.
+ *
+ * VM_BIND/UNBIND ioctl calls executed on different CPU threads concurrently
+ * are not ordered. Furthermore, parts

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Flush to global observation point before breadcrumb write (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gt: Flush to global observation point before breadcrumb write 
(rev2)
URL   : https://patchwork.freedesktop.org/series/109133/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2

Re: [Intel-gfx] [PATCH] drm/i915: Fix CFI violations in gt_sysfs

[Andi Shyti]

Hi Nathan,

thanks for this refactoring... looks good even though i would
have split it in more patches as this is doing quite many things.

But I will not be stubborn, I understand that it's not trivial to
have things split. I will give my r-b for now but I will check it
again before applying it as it's very easy to get tangled-up in
between all those defines:

Reviewed-by: Andi Shyti 

For now I'm quite surprised to see how easily our CI gives green
lights :-P

On Sat, Sep 24, 2022 at 09:39:30PM -0700, Nathan Chancellor wrote:
> On Fri, Sep 23, 2022 at 09:57:47PM -0700, Kees Cook wrote:
> > On Thu, Sep 22, 2022 at 12:51:27PM -0700, Nathan Chancellor wrote:
> > > [...]
> > > To make everything work properly, adjust certain functions to match the
> > > type of the ->show() and ->store() members in 'struct kobj_attribute'.
> > > Add a macro to generate functions for that can be called via both
> > > dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
> > > called through both kobject locations without violating kCFI and adjust
> > > the attribute groups to account for this.
> > 
> > This was quite a roller coaster! I think the solution looks good, even
> > if I'm suspicious of the original design that has the same stuff
> > available twice in different places. (I have a dim memory of rdma
> > needing a refactoring like this too?)
> 
> Right, I noticed this comment in intel_gt_sysfs_register() once I fully
> saw what was going on:
> 
>   /*
>* We need to make things right with the
>* ABI compatibility. The files were originally
>* generated under the parent directory.
>*
>* We generate the files only for gt 0
>* to avoid duplicates.
>*/
> 
> Makes it seem like there will be userspace breakage if these files do
> not exist? I figured this was the cleanest solution within those
> parameters.

i915 went multi-gt (multitile) so that some interfaces, like the
power management files, have effect only on one of the tiles.
This means that we needed to move some of the files inside the
newly created gt0/gt1 directory.

But, because some of those files are part of an ABI
specification, we can't simply transfer them from the original
position so that we needed to make a "hard" copy (actually the
original files now take the role of affecting all the GTs instead
of only one).

The complexity of this file comes from the necessity of
minimizing code duplication, otherwise we could have had two
perfectly identical files (which looking at the final result it
wouldn't have been a completely bad idea after all).

Thanks again, will let you know when I will get this into our
branch.

Andi

> > Reviewed-by: Kees Cook 
> 
> Thanks for looking it over!
> 
> Cheers,
> Nathan

Re: [Intel-gfx] [PATCH] drm/i915/guc: do not capture error state on exiting context

[John Harrison]

On 9/29/2022 01:22, Tvrtko Ursulin wrote:

On 28/09/2022 19:27, John Harrison wrote:

On 9/28/2022 00:19, Tvrtko Ursulin wrote:

On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:

On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote:

On 27/09/2022 07:49, Andrzej Hajda wrote:

On 27.09.2022 01:34, Ceraolo Spurio, Daniele wrote:

On 9/26/2022 3:44 PM, Andi Shyti wrote:

Hi Andrzej,

On Mon, Sep 26, 2022 at 11:54:09PM +0200, Andrzej Hajda wrote:
Capturing error state is time consuming (up to 350ms on DG2), 
so it should
be avoided if possible. Context reset triggered by context 
removal is a

good example.
With this patch multiple igt tests will not timeout and should 
run faster.


Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6268
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6281
Signed-off-by: Andrzej Hajda 

fine for me:

Reviewed-by: Andi Shyti 

Just to be on the safe side, can we also have the ack from any of
the GuC folks? Daniele, John?

Andi



---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index 22ba66e48a9b01..cb58029208afe1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4425,7 +4425,8 @@ static void 
guc_handle_context_reset(struct intel_guc *guc,

  trace_intel_context_reset(ce);
    if (likely(!intel_context_is_banned(ce))) {
-    capture_error_state(guc, ce);
+    if (!intel_context_is_exiting(ce))
+    capture_error_state(guc, ce);


I am not sure here - if we have a persistent context which caused 
a GPU hang I'd expect we'd still want error capture.


What causes the reset in the affected IGTs? Always preemption 
timeout?



guc_context_replay(ce);


You definitely don't want to replay requests of a context that 
is going away.


My intention was to just avoid error capture, but that's even 
better, only condition change:

-        if (likely(!intel_context_is_banned(ce))) {
+       if (likely(intel_context_is_schedulable(ce)))  {


Yes that helper was intended to be used for contexts which should 
not be scheduled post exit or ban.


Daniele - you say there are some misses in the GuC backend. Should 
most, or even all in intel_guc_submission.c be converted to use 
intel_context_is_schedulable? My idea indeed was that "ban" should 
be a level up from the backends. Backend should only distinguish 
between "should I run this or not", and not the reason.


I think that all of them should be updated, but I'd like Matt B to 
confirm as he's more familiar with the code than me.


Right, that sounds plausible to me as well.

One thing I forgot to mention - the only place where backend can 
care between "schedulable" and "banned" is when it picks the preempt 
timeout for non-schedulable contexts. This is to only apply the 
strict 1ms to banned (so bad or naught contexts), while the ones 
which are exiting cleanly get the full preempt timeout as otherwise 
configured. This solves the ugly user experience quirk where GPU 
resets/errors were logged upon exit/Ctrl-C of a well behaving 
application (using non-persistent contexts). Hopefully GuC can match 
that behaviour so customers stay happy.


Regards,

Tvrtko


The whole revoke vs ban thing seems broken to me.

First of all, if the user hits Ctrl+C we need to kill the context off 
immediately. That is a fundamental customer requirement. Render and 
compute engines have a 7.5s pre-emption timeout. The user should not 
have to wait 7.5s for a context to be removed from the system when 
they have explicitly killed it themselves. Even the regular timeout 
of 640ms is borderline a long time to wait. And note that there is an 
ongoing request/requirement to increase that to 1900ms.


Under what circumstances would a user expect anything sensible to 
happen after a Ctrl+C in terms of things finishing their rendering 
and display nice pretty images? They killed the app. They want it 
dead. We should be getting it off the hardware as quickly as 
possible. If you are really concerned about resets causing collateral 
damage then maybe bump the termination timeout from 1ms up to 10ms, 
maybe at most 100ms. If an app is 'well behaved' then it should 
cleanly exit within 10ms. But if it is bad (which is almost certainly 
the case if the user is manually and explicitly killing it) then it 
needs to be killed because it is not going to gracefully exit.


Right.. I had it like that initially (lower timeout - I think 20ms or 
so, patch history on the mailing list would know for sure), but then 
simplified it after review feedback to avoid adding another timeout 
value.


So it's not at