[Intel-gfx] [PATCH v6 6/6] drm/i915/panelreplay: Debugfs support for panel replay

2023-09-20 Thread Animesh Manna
Add debugfs support which will print source and sink status
per connector basis.

Cc: Jouni Högander 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 132 +--
 1 file changed, 97 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 67337b4a421b..65f22e4ff3b2 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -2834,6 +2834,25 @@ static int psr_get_status_and_error_status(struct 
intel_dp *intel_dp,
return 0;
 }
 
+static int panel_replay_get_status_and_error_status(struct intel_dp *intel_dp,
+   u8 *status, u8 
*error_status)
+{
+   struct drm_dp_aux *aux = &intel_dp->aux;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS, 
status);
+   if (ret != 1)
+   return ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_PANEL_REPLAY_ERROR_STATUS, 
error_status);
+   if (ret != 1)
+   return ret;
+
+   *status = *status & DP_PSR_SINK_STATE_MASK;
+
+   return 0;
+}
+
 static void psr_alpm_check(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -3046,7 +3065,7 @@ psr_source_status(struct intel_dp *intel_dp, struct 
seq_file *m)
status = live_status[status_val];
}
 
-   seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
+   seq_printf(m, "Source PSR/PanelReplay status: %s [0x%08x]\n", status, 
val);
 }
 
 static int intel_psr_status(struct seq_file *m, struct intel_dp *intel_dp)
@@ -3059,18 +3078,23 @@ static int intel_psr_status(struct seq_file *m, struct 
intel_dp *intel_dp)
bool enabled;
u32 val;
 
-   seq_printf(m, "Sink support: %s", str_yes_no(psr->sink_support));
-   if (psr->sink_support)
+   seq_printf(m, "Sink support: PSR = %s, Panel Replay = %s",
+  str_yes_no(psr->sink_support),
+  str_yes_no(psr->sink_panel_replay_support));
+
+   if (psr->sink_support || psr->sink_panel_replay_support)
seq_printf(m, " [0x%02x]", intel_dp->psr_dpcd[0]);
seq_puts(m, "\n");
 
-   if (!psr->sink_support)
+   if (!(psr->sink_support || psr->sink_panel_replay_support))
return 0;
 
wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
mutex_lock(&psr->lock);
 
-   if (psr->enabled)
+   if (psr->panel_replay_enabled)
+   status = "Panel Replay Enabled";
+   else if (psr->enabled)
status = psr->psr2_enabled ? "PSR2 enabled" : "PSR1 enabled";
else
status = "disabled";
@@ -3083,14 +3107,17 @@ static int intel_psr_status(struct seq_file *m, struct 
intel_dp *intel_dp)
goto unlock;
}
 
-   if (psr->psr2_enabled) {
+   if (psr->panel_replay_enabled) {
+   val = intel_de_read(dev_priv, TRANS_DP2_CTL(cpu_transcoder));
+   enabled = val & TRANS_DP2_PANEL_REPLAY_ENABLE;
+   } else if (psr->psr2_enabled) {
val = intel_de_read(dev_priv, EDP_PSR2_CTL(cpu_transcoder));
enabled = val & EDP_PSR2_ENABLE;
} else {
val = intel_de_read(dev_priv, psr_ctl_reg(dev_priv, 
cpu_transcoder));
enabled = val & EDP_PSR_ENABLE;
}
-   seq_printf(m, "Source PSR ctl: %s [0x%08x]\n",
+   seq_printf(m, "Source PSR/PanelReplay ctl: %s [0x%08x]\n",
   str_enabled_disabled(enabled), val);
psr_source_status(intel_dp, m);
seq_printf(m, "Busy frontbuffer bits: 0x%08x\n",
@@ -3232,6 +3259,7 @@ static int i915_psr_sink_status_show(struct seq_file *m, 
void *data)
 {
struct intel_connector *connector = m->private;
struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct intel_psr *psr = &intel_dp->psr;
static const char * const sink_status[] = {
"inactive",
"transition to active, capture and display",
@@ -3242,45 +3270,82 @@ static int i915_psr_sink_status_show(struct seq_file 
*m, void *data)
"reserved",
"sink internal error",
};
+   static const char * const panel_replay_status[] = {
+   "Sink device frame is locked to the Source device",
+   "Sink device is coasting, using the VTotal target",
+   "Sink device is governing the frame rate (frame rate unlock is 
granted)",
+   "Sink device in the process of re-locking with the Source 
device",
+   };
const char *str;
int ret;
u8 status, error_status;
 
-   if (!CAN_PSR(intel_dp)) {
-   seq_puts(m, "PSR Unsupported\n");
+   if (!(CAN_PSR(intel_dp) || CAN_PANEL_REPLAY(intel_dp))) {
+   seq_puts(m, "PSR/Panel-Replay Unsu

[Intel-gfx] [PATCH v6 5/6] drm/i915/panelreplay: enable/disable panel replay

2023-09-20 Thread Animesh Manna
TRANS_DP2_CTL register is programmed to enable panel replay from source
and sink is enabled through panel replay dpcd configuration address.

Bspec: 1407940617

v1: Initial version.
v2:
- Use pr_* flags instead psr_* flags. [Jouni]
- Remove intel_dp_is_edp check as edp1.5 also has panel replay. [Jouni]

v3: Cover letter updated and selective fetch condition check is added
before updating its bit in PSR2_MAN_TRK_CTL register. [Jouni]

v4: Selective fetch related PSR2_MAN_TRK_CTL programmming dropped. [Jouni]

v5: Added PSR2_MAN_TRK_CTL programming as needed for Continuous Full
Frame (CFF) update.

Note: Initial plan is to enable panel replay in  full-screen live active
frame update mode. In a incremental approach panel replay will be enabled
in selctive update mode if there is any gap in curent implementation.

Cc: Jouni Högander 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  7 +-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_psr.c  | 65 ++-
 3 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4668de45d6fe..203c56c5e208 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2717,10 +2717,15 @@ static void intel_ddi_pre_enable_dp(struct 
intel_atomic_state *state,
const struct drm_connector_state 
*conn_state)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
-   if (HAS_DP20(dev_priv))
+   if (HAS_DP20(dev_priv)) {
intel_dp_128b132b_sdp_crc16(enc_to_intel_dp(encoder),
crtc_state);
+   if (crtc_state->has_panel_replay)
+   drm_dp_dpcd_writeb(&intel_dp->aux, PANEL_REPLAY_CONFIG,
+  DP_PANEL_REPLAY_ENABLE);
+   }
 
if (DISPLAY_VER(dev_priv) >= 14)
mtl_ddi_pre_enable_dp(state, encoder, crtc_state, conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3eadd8e12f63..1cf302e9deed 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1698,6 +1698,7 @@ struct intel_psr {
u16 su_y_granularity;
bool source_panel_replay_support;
bool sink_panel_replay_support;
+   bool panel_replay_enabled;
u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index a59f13c29c3d..67337b4a421b 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -607,8 +607,11 @@ static void intel_psr_enable_sink(struct intel_dp 
*intel_dp)
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u8 dpcd_val = DP_PSR_ENABLE;
 
-   /* Enable ALPM at sink for psr2 */
+   if (intel_dp->psr.panel_replay_enabled)
+   return;
+
if (intel_dp->psr.psr2_enabled) {
+   /* Enable ALPM at sink for psr2 */
drm_dp_dpcd_writeb(&intel_dp->aux, DP_RECEIVER_ALPM_CONFIG,
   DP_ALPM_ENABLE |
   DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE);
@@ -758,6 +761,17 @@ static int psr2_block_count(struct intel_dp *intel_dp)
return psr2_block_count_lines(intel_dp) / 4;
 }
 
+static void dg2_activate_panel_replay(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+   intel_de_rmw(dev_priv, PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
+0, ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME);
+
+   intel_de_rmw(dev_priv, TRANS_DP2_CTL(intel_dp->psr.transcoder), 0,
+TRANS_DP2_PANEL_REPLAY_ENABLE);
+}
+
 static void hsw_activate_psr2(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -1322,18 +1336,23 @@ void intel_psr_get_config(struct intel_encoder *encoder,
return;
 
intel_dp = &dig_port->dp;
-   if (!CAN_PSR(intel_dp))
+   if (!(CAN_PSR(intel_dp) || CAN_PANEL_REPLAY(intel_dp)))
return;
 
mutex_lock(&intel_dp->psr.lock);
if (!intel_dp->psr.enabled)
goto unlock;
 
-   /*
-* Not possible to read EDP_PSR/PSR2_CTL registers as it is
-* enabled/disabled because of frontbuffer tracking and others.
-*/
-   pipe_config->has_psr = true;
+   if (intel_dp->psr.panel_replay_enabled) {
+   pipe_config->has_panel_replay = true;
+   } else {
+   /*
+* Not possible to read

[Intel-gfx] [PATCH v6 4/6] drm/i915/panelreplay: Enable panel replay dpcd initialization for DP

2023-09-20 Thread Animesh Manna
Due to similarity panel replay dpcd initialization got added in psr
function which is specific for edp panel. This patch enables panel
replay initialization for dp connector.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 2427bd5cb7ca..a59f13c29c3d 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -2749,6 +2749,9 @@ void intel_psr_init(struct intel_dp *intel_dp)
if (!(HAS_PSR(dev_priv) || HAS_DP20(dev_priv)))
return;
 
+   if (!intel_dp_is_edp(intel_dp))
+   intel_psr_init_dpcd(intel_dp);
+
/*
 * HSW spec explicitly says PSR is tied to port A.
 * BDW+ platforms have a instance of PSR registers per transcoder but
-- 
2.29.0



[Intel-gfx] [PATCH v6 3/6] drm/i915/panelreplay: Initializaton and compute config for panel replay

2023-09-20 Thread Animesh Manna
Modify existing PSR implementation to enable panel replay feature of DP 2.0
which is similar to PSR feature of EDP panel. There is different DPCD
address to check panel capability compare to PSR and vsc sdp header
is different.

v1: Initial version.
v2:
- Set source_panel_replay_support flag under HAS_PANEL_REPLAY()
condition check. [Jouni]
- Code restructured around intel_panel_replay_init
and renamed to intel_panel_replay_init_dpcd. [Jouni]
- Remove the initial code modification around has_psr2 flag. [Jouni]
- Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to
enable in intel_psr_post_plane_update. [Jouni]
v3:
- Initialize both psr and panel-replay. [Jouni]
- Initialize both panel replay and psr if detected. [Jouni]
- Refactoring psr function by introducing _psr_compute_config(). [Jouni]
- Add check for !is_edp while deriving source_panel_replay_support. [Jouni]
- Enable panel replay dpcd initialization in a separate patch. [Jouni]

v4:
- HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni]
- Set either panel replay source support or psr. [Jouni]

v5:
- HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni]
- Move psr related code to intel_psr.c. [Jani]
- Reset sink_panel_replay_support flag during disconnection. [Jani]

v6: return statement restored which is removed by misatke. [Jouni]

Cc: Jouni Högander 
Signed-off-by: Animesh Manna 
---
 .../drm/i915/display/intel_display_types.h| 14 +--
 drivers/gpu/drm/i915/display/intel_dp.c   | 50 --
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +
 drivers/gpu/drm/i915/display/intel_psr.c  | 95 ++-
 drivers/gpu/drm/i915/display/intel_psr.h  |  7 ++
 5 files changed, 123 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 2213ad6c00da..3eadd8e12f63 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1203,6 +1203,7 @@ struct intel_crtc_state {
bool has_psr2;
bool enable_psr2_sel_fetch;
bool req_psr2_sdp_prior_scanline;
+   bool has_panel_replay;
bool wm_level_disabled;
u32 dc3co_exitline;
u16 su_y_granularity;
@@ -1695,6 +1696,8 @@ struct intel_psr {
bool irq_aux_error;
u16 su_w_granularity;
u16 su_y_granularity;
+   bool source_panel_replay_support;
+   bool sink_panel_replay_support;
u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
@@ -1982,17 +1985,6 @@ dp_to_lspcon(struct intel_dp *intel_dp)
 
 #define dp_to_i915(__intel_dp) 
to_i915(dp_to_dig_port(__intel_dp)->base.base.dev)
 
-#define CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \
-  (intel_dp)->psr.source_support)
-
-static inline bool intel_encoder_can_psr(struct intel_encoder *encoder)
-{
-   if (!intel_encoder_is_dp(encoder))
-   return false;
-
-   return CAN_PSR(enc_to_intel_dp(encoder));
-}
-
 static inline struct intel_digital_port *
 hdmi_to_dig_port(struct intel_hdmi *intel_hdmi)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index f16d9fa88fe1..1c7d9b14fd1c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2338,12 +2338,22 @@ static void intel_dp_compute_vsc_colorimetry(const 
struct intel_crtc_state *crtc
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
 
-   /*
-* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
-* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
-* Colorimetry Format indication.
-*/
-   vsc->revision = 0x5;
+   if (crtc_state->has_panel_replay) {
+   /*
+* Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
+* VSC SDP supporting 3D stereo, Panel Replay, and Pixel
+* Encoding/Colorimetry Format indication.
+*/
+   vsc->revision = 0x7;
+   } else {
+   /*
+* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
+* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
+* Colorimetry Format indication.
+*/
+   vsc->revision = 0x5;
+   }
+
vsc->length = 0x13;
 
/* DP 1.4a spec, Table 2-120 */
@@ -2452,6 +2462,21 @@ void intel_dp_compute_psr_vsc_sdp(struct intel_dp 
*intel_dp,
vsc->revision = 0x4;
vsc->length = 0xe;
}
+   } else if (crtc_state->has_panel_replay) {
+   if (intel_dp->psr.colorimetry_support &&
+   intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
+   /* [P

[Intel-gfx] [PATCH v6 2/6] drm/i915/psr: Move psr specific dpcd init into own function

2023-09-20 Thread Animesh Manna
From: Jouni Högander 

This patch is preparing adding panel replay specific dpcd init.

Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 41 +---
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 850b11f20285..71fe2e4aca85 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -474,27 +474,22 @@ static void intel_dp_get_su_granularity(struct intel_dp 
*intel_dp)
intel_dp->psr.su_y_granularity = y;
 }
 
-void intel_psr_init_dpcd(struct intel_dp *intel_dp)
+static void _psr_init_dpcd(struct intel_dp *intel_dp)
 {
-   struct drm_i915_private *dev_priv =
+   struct drm_i915_private *i915 =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
 
-   drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
-sizeof(intel_dp->psr_dpcd));
-
-   if (!intel_dp->psr_dpcd[0])
-   return;
-   drm_dbg_kms(&dev_priv->drm, "eDP panel supports PSR version %x\n",
+   drm_dbg_kms(&i915->drm, "eDP panel supports PSR version %x\n",
intel_dp->psr_dpcd[0]);
 
if (drm_dp_has_quirk(&intel_dp->desc, DP_DPCD_QUIRK_NO_PSR)) {
-   drm_dbg_kms(&dev_priv->drm,
+   drm_dbg_kms(&i915->drm,
"PSR support not currently available for this 
panel\n");
return;
}
 
if (!(intel_dp->edp_dpcd[1] & DP_EDP_SET_POWER_CAP)) {
-   drm_dbg_kms(&dev_priv->drm,
+   drm_dbg_kms(&i915->drm,
"Panel lacks power state control, PSR cannot be 
enabled\n");
return;
}
@@ -503,8 +498,8 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
intel_dp->psr.sink_sync_latency =
intel_dp_get_sink_sync_latency(intel_dp);
 
-   if (DISPLAY_VER(dev_priv) >= 9 &&
-   (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
+   if (DISPLAY_VER(i915) >= 9 &&
+   intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED) {
bool y_req = intel_dp->psr_dpcd[1] &
 DP_PSR2_SU_Y_COORDINATE_REQUIRED;
bool alpm = intel_dp_get_alpm_status(intel_dp);
@@ -521,14 +516,24 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
 * GTC first.
 */
intel_dp->psr.sink_psr2_support = y_req && alpm;
-   drm_dbg_kms(&dev_priv->drm, "PSR2 %ssupported\n",
+   drm_dbg_kms(&i915->drm, "PSR2 %ssupported\n",
intel_dp->psr.sink_psr2_support ? "" : "not ");
+   }
+}
 
-   if (intel_dp->psr.sink_psr2_support) {
-   intel_dp->psr.colorimetry_support =
-   intel_dp_get_colorimetry_status(intel_dp);
-   intel_dp_get_su_granularity(intel_dp);
-   }
+void intel_psr_init_dpcd(struct intel_dp *intel_dp)
+{
+   drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd));
+
+   if (intel_dp->psr_dpcd[0])
+   _psr_init_dpcd(intel_dp);
+   /* TODO: Add PR case here */
+
+   if (intel_dp->psr.sink_psr2_support) {
+   intel_dp->psr.colorimetry_support =
+   intel_dp_get_colorimetry_status(intel_dp);
+   intel_dp_get_su_granularity(intel_dp);
}
 }
 
-- 
2.29.0



[Intel-gfx] [PATCH v6 1/6] drm/panelreplay: dpcd register definition for panelreplay

2023-09-20 Thread Animesh Manna
Add DPCD register definition for discovering, enabling and
checking status of panel replay of the sink.

Cc: Jouni Högander 
Signed-off-by: Animesh Manna 
---
 include/drm/display/drm_dp.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index e69cece404b3..fc42b622ef32 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -543,6 +543,10 @@
 /* DFP Capability Extension */
 #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0a3   /* 2.0 */
 
+#define DP_PANEL_REPLAY_CAP 0x0b0  /* DP 2.0 */
+# define DP_PANEL_REPLAY_SUPPORT(1 << 0)
+# define DP_PANEL_REPLAY_SU_SUPPORT (1 << 1)
+
 /* Link Configuration */
 #defineDP_LINK_BW_SET  0x100
 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */
@@ -716,6 +720,13 @@
 #define DP_BRANCH_DEVICE_CTRL  0x1a1
 # define DP_BRANCH_DEVICE_IRQ_HPD  (1 << 0)
 
+#define PANEL_REPLAY_CONFIG 0x1b0  /* DP 2.0 */
+# define DP_PANEL_REPLAY_ENABLE (1 << 0)
+# define DP_PANEL_REPLAY_UNRECOVERABLE_ERROR_EN (1 << 3)
+# define DP_PANEL_REPLAY_RFB_STORAGE_ERROR_EN   (1 << 4)
+# define DP_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR_EN  (1 << 5)
+# define DP_PANEL_REPLAY_SU_ENABLE  (1 << 6)
+
 #define DP_PAYLOAD_ALLOCATE_SET0x1c0
 #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1
 #define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2
@@ -1105,6 +1116,18 @@
 #define DP_LANE_ALIGN_STATUS_UPDATED_ESI   0x200e /* status same as 0x204 
*/
 #define DP_SINK_STATUS_ESI 0x200f /* status same as 0x205 
*/
 
+#define DP_PANEL_REPLAY_ERROR_STATUS   0x2020  /* DP 2.1*/
+# define DP_PANEL_REPLAY_LINK_CRC_ERROR(1 << 0)
+# define DP_PANEL_REPLAY_RFB_STORAGE_ERROR (1 << 1)
+# define DP_PANEL_REPLAY_VSC_SDP_UNCORRECTABLE_ERROR   (1 << 2)
+
+#define DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS0x2022  /* DP 2.1 */
+# define DP_SINK_DEVICE_PANEL_REPLAY_STATUS_MASK   (7 << 0)
+# define DP_SINK_FRAME_LOCKED_SHIFT3
+# define DP_SINK_FRAME_LOCKED_MASK (3 << 3)
+# define DP_SINK_FRAME_LOCKED_STATUS_VALID_SHIFT   5
+# define DP_SINK_FRAME_LOCKED_STATUS_VALID_MASK(1 << 5)
+
 /* Extended Receiver Capability: See DP_DPCD_REV for definitions */
 #define DP_DP13_DPCD_REV0x2200
 
-- 
2.29.0



[Intel-gfx] [PATCH v6 0/6] Panel replay phase1 implementation

2023-09-20 Thread Animesh Manna
Panel Replay is a power saving feature for DP 2.0 monitor and similar
to PSR on EDP.

These patches are basic enablement patches added on top of
existing psr framework to enable full-screen live active frame
update mode of panel replay. Panel replay also can be enabled
in selective update mode which will be enabled in a incremental
approach.

As per current design panel replay priority is higher than psr.
intel_dp->psr.panel_replay_enabled flag indicate panel replay is enabled.
intel_dp->psr.panel_replay_enabled + intel_dp->psr.psr2_enabled indicates
panel replay is enabled in selective update mode.
intel_dp->psr.panel_replay_enabled + intel_dp->psr.psr2_enabled +
intel_psr.selective_fetch enabled indicates panel replay is
enabled in selective update mode with selective fetch.
PSR replated flags remain same like before.

Note: The patches are under testing by using panel replay emulator and
panel is not avalible.

Cc: Jouni Högander 
Signed-off-by: Animesh Manna 

Animesh Manna (5):
  drm/panelreplay: dpcd register definition for panelreplay
  drm/i915/panelreplay: Initializaton and compute config for panel
replay
  drm/i915/panelreplay: Enable panel replay dpcd initialization for DP
  drm/i915/panelreplay: enable/disable panel replay
  drm/i915/panelreplay: Debugfs support for panel replay

Jouni Högander (1):
  drm/i915/psr: Move psr specific dpcd init into own function

 drivers/gpu/drm/i915/display/intel_ddi.c  |   7 +-
 .../drm/i915/display/intel_display_types.h|  15 +-
 drivers/gpu/drm/i915/display/intel_dp.c   |  50 ++-
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |   3 +
 drivers/gpu/drm/i915/display/intel_psr.c  | 332 +-
 drivers/gpu/drm/i915/display/intel_psr.h  |   7 +
 include/drm/display/drm_dp.h  |  23 ++
 7 files changed, 323 insertions(+), 114 deletions(-)

-- 
2.29.0



[Intel-gfx] [PATCH v4 2/2] drm/i915/hdcp: Move common message filling function to its own file

2023-09-20 Thread Suraj Kandpal
Create a new file intel_hdcp_gsc_message that contain functions
which fill the hdcp messages we send to gsc cs this refactor will
help us reuse code for Xe later on

--v2
-add the missed file for proper build

--v3
-use forward declarations instead of #includes [Jani]

--v4
-move linux/err.h to intel_hdcp_gsc_message.c from
intel_hdcp_gsc_message.h [Jani]

Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 615 +-
 .../drm/i915/display/intel_hdcp_gsc_message.c | 592 +
 .../drm/i915/display/intel_hdcp_gsc_message.h |  72 ++
 4 files changed, 682 insertions(+), 598 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1b2e02e9d92c..27b3da6e0e43 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -265,6 +265,7 @@ i915-y += \
display/intel_global_state.o \
display/intel_hdcp.o \
display/intel_hdcp_gsc.o \
+   display/intel_hdcp_gsc_message.o \
display/intel_hotplug.o \
display/intel_hotplug_irq.o \
display/intel_hti.o \
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c 
b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
index d355d610bc9f..18117b789b16 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
@@ -11,6 +11,7 @@
 #include "i915_drv.h"
 #include "i915_utils.h"
 #include "intel_hdcp_gsc.h"
+#include "intel_hdcp_gsc_message.h"
 
 bool intel_hdcp_gsc_cs_required(struct drm_i915_private *i915)
 {
@@ -31,604 +32,6 @@ bool intel_hdcp_gsc_check_status(struct drm_i915_private 
*i915)
return true;
 }
 
-static int
-gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
- struct hdcp2_ake_init *ake_data)
-{
-   struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
-   struct wired_cmd_initiate_hdcp2_session_out
-   session_init_out = { { 0 } };
-   struct drm_i915_private *i915;
-   ssize_t byte;
-
-   if (!dev || !data || !ake_data)
-   return -EINVAL;
-
-   i915 = kdev_to_i915(dev);
-   if (!i915) {
-   dev_err(dev, "DRM not initialized, aborting HDCP.\n");
-   return -ENODEV;
-   }
-
-   session_init_in.header.api_version = HDCP_API_VERSION;
-   session_init_in.header.command_id = WIRED_INITIATE_HDCP2_SESSION;
-   session_init_in.header.status = FW_HDCP_STATUS_SUCCESS;
-   session_init_in.header.buffer_len =
-   WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
-
-   session_init_in.port.integrated_port_type = data->port_type;
-   session_init_in.port.physical_port = (u8)data->hdcp_ddi;
-   session_init_in.port.attached_transcoder = (u8)data->hdcp_transcoder;
-   session_init_in.protocol = data->protocol;
-
-   byte = intel_hdcp_gsc_msg_send(i915, (u8 *)&session_init_in,
-  sizeof(session_init_in),
-  (u8 *)&session_init_out,
-  sizeof(session_init_out));
-   if (byte < 0) {
-   drm_dbg_kms(&i915->drm, "intel_hdcp_gsc_msg_send failed. 
%zd\n", byte);
-   return byte;
-   }
-
-   if (session_init_out.header.status != FW_HDCP_STATUS_SUCCESS) {
-   drm_dbg_kms(&i915->drm, "FW cmd 0x%08X Failed. Status: 0x%X\n",
-   WIRED_INITIATE_HDCP2_SESSION,
-   session_init_out.header.status);
-   return -EIO;
-   }
-
-   ake_data->msg_id = HDCP_2_2_AKE_INIT;
-   ake_data->tx_caps = session_init_out.tx_caps;
-   memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
-
-   return 0;
-}
-
-static int
-gsc_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
-struct hdcp_port_data *data,
-struct hdcp2_ake_send_cert *rx_cert,
-bool *km_stored,
-struct hdcp2_ake_no_stored_km
-   *ek_pub_km,
-size_t *msg_sz)
-{
-   struct wired_cmd_verify_receiver_cert_in verify_rxcert_in = { { 0 } };
-   struct wired_cmd_verify_receiver_cert_out verify_rxcert_out = { { 0 } };
-   struct drm_i915_private *i915;
-   ssize_t byte;
-
-   if (!dev || !data || !rx_cert || !km_stored || !ek_pub_km || !msg_sz)
-   return -EINVAL;
-
-   i915 = kdev_to_i915(dev);
-   if (!i915) {
-   dev_err(dev, "DRM not initialized, abort

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/dp: Change DSC vs lower bpp priority

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915/display/dp: Change DSC vs lower bpp priority
URL   : https://patchwork.freedesktop.org/series/124022/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13659 -> Patchwork_124022v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-hsw-4770:[PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-hsw-4770/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-mtlp-8: NOTRUN -> [ABORT][3] ([i915#9262])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
- bat-jsl-1:  [PASS][4] -> [INCOMPLETE][5] ([i915#9275])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-jsl-1/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-jsl-1/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [PASS][6] -> [TIMEOUT][7] ([i915#6794] / [i915#7392])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-rpls-1/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-1: [PASS][8] -> [WARN][9] ([i915#8747])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#6645])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
- bat-jsl-1:  [PASS][11] -> [FAIL][12] ([fdo#103375])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-jsl-1/igt@i915_susp...@basic-s3-without-i915.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-jsl-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][13] ([i915#3546]) +2 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg2-9:  [INCOMPLETE][14] ([i915#8797] / [i915#9275]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [DMESG-FAIL][16] ([i915#5334]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
- bat-dg2-11: [INCOMPLETE][18] ([i915#7609] / [i915#7913]) -> 
[PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [ABORT][20] ([i915#9262]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][22] ([IGT#3] / [i915#6121]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124022v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  
 Warnings 

  * igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: [ABORT][24] ([i915#7978] / [i915#8668]) -> 
[INCOMPLETE][25] ([i915#9136])
   [24]: 
https://intel-gfx-ci.01.org/tree

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Add Wa_18028616096 (rev2)

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Add Wa_18028616096 (rev2)
URL   : https://patchwork.freedesktop.org/series/123951/
State : failure

== Summary ==

Error: make failed
  CALLscripts/checksyscalls.sh
  DESCEND objtool
  INSTALL libsubcmd_headers
  CC [M]  drivers/gpu/drm/i915/gt/intel_workarounds.o
In file included from ./drivers/gpu/drm/i915/intel_uncore.h:34,
 from ./drivers/gpu/drm/i915/gt/intel_engine_types.h:26,
 from ./drivers/gpu/drm/i915/gt/intel_context_types.h:18,
 from ./drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20,
 from ./drivers/gpu/drm/i915/i915_drv.h:42,
 from drivers/gpu/drm/i915/gt/intel_workarounds.c:6:
drivers/gpu/drm/i915/gt/intel_workarounds.c: In function 
‘general_render_compute_wa_init’:
./drivers/gpu/drm/i915/i915_reg_defs.h:273:25: error: incompatible type for 
argument 3 of ‘wa_mcr_write_or’
  273 | #define MCR_REG(offset) ((const i915_mcr_reg_t){ .reg = (offset) })
  | ^~~
  | |
  | i915_mcr_reg_t {aka const struct }
drivers/gpu/drm/i915/gt/intel_gt_regs.h:1235:40: note: in expansion of macro 
‘MCR_REG’
 1235 | #define   UGM_FRAGMENT_THRESHOLD_TO_3  MCR_REG(58 - 32)
  |^~~
drivers/gpu/drm/i915/gt/intel_workarounds.c:2919:47: note: in expansion of 
macro ‘UGM_FRAGMENT_THRESHOLD_TO_3’
 2919 |   wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW, 
UGM_FRAGMENT_THRESHOLD_TO_3);
  |   
^~~
drivers/gpu/drm/i915/gt/intel_workarounds.c:272:67: note: expected ‘u32’ {aka 
‘unsigned int’} but argument is of type ‘i915_mcr_reg_t’ {aka ‘const struct 
’}
  272 | wa_mcr_write_or(struct i915_wa_list *wal, i915_mcr_reg_t reg, u32 set)
  |   ^~~
make[6]: *** [scripts/Makefile.build:243: 
drivers/gpu/drm/i915/gt/intel_workarounds.o] Error 1
make[5]: *** [scripts/Makefile.build:480: drivers/gpu/drm/i915] Error 2
make[4]: *** [scripts/Makefile.build:480: drivers/gpu/drm] Error 2
make[3]: *** [scripts/Makefile.build:480: drivers/gpu] Error 2
make[2]: *** [scripts/Makefile.build:480: drivers] Error 2
make[1]: *** [/home/kbuild2/kernel/Makefile:1913: .] Error 2
make: *** [Makefile:234: __sub-make] Error 2
Build failed, no error log produced




[Intel-gfx] [PATCH] drm/i915: Add Wa_18028616096

2023-09-20 Thread Shekhar Chauhan
Drop UGM per set fragment threshold to 3

BSpec: 54833
Signed-off-by: Shekhar Chauhan 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index a00ff51c681d..326224abe395 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1230,6 +1230,7 @@
 #define   DISABLE_D8_D16_COASLESCE REG_BIT(30)
 #define   FORCE_1_SUB_MESSAGE_PER_FRAGMENT REG_BIT(15)
 #define LSC_CHICKEN_BIT_0_UDW  MCR_REG(0xe7c8 + 4)
+#define   UGM_FRAGMENT_THRESHOLD_TO_3  MCR_REG(58 - 32)
 #define   DIS_CHAIN_2XSIMD8REG_BIT(55 - 32)
 #define   FORCE_SLM_FENCE_SCOPE_TO_TILEREG_BIT(42 - 32)
 #define   FORCE_UGM_FENCE_SCOPE_TO_TILEREG_BIT(41 - 32)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 660d4f358eab..992041e3776c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2914,6 +2914,9 @@ general_render_compute_wa_init(struct intel_engine_cs 
*engine, struct i915_wa_li
 * Wa_22015475538:dg2
 */
wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
+
+   /* Wa_18028616096:dg2 */
+   wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW, 
UGM_FRAGMENT_THRESHOLD_TO_3);
}
 
if (IS_DG2_G11(i915)) {
-- 
2.34.1



[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Allow users to disable waitboost

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: Allow users to disable waitboost
URL   : https://patchwork.freedesktop.org/series/124016/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13659 -> Patchwork_124016v1


Summary
---

  **FAILURE**

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

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

Participating hosts (40 -> 35)
--

  Additional (1): bat-dg2-8 
  Missing(6): bat-kbl-2 fi-bsw-n3050 fi-apl-guc fi-snb-2520m fi-cfl-8109u 
fi-skl-6600u 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@core_hotunplug@unbind-rebind:
- bat-atsm-1: [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-atsm-1/igt@core_hotunp...@unbind-rebind.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-atsm-1/igt@core_hotunp...@unbind-rebind.html

  * igt@gem_exec_basic@basic:
- bat-dg1-5:  NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-dg1-5/igt@gem_exec_ba...@basic.html
- bat-dg2-11: NOTRUN -> [INCOMPLETE][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-dg2-11/igt@gem_exec_ba...@basic.html
- bat-atsm-1: NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-atsm-1/igt@gem_exec_ba...@basic.html
- bat-dg2-9:  NOTRUN -> [INCOMPLETE][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-dg2-9/igt@gem_exec_ba...@basic.html
- bat-dg2-8:  NOTRUN -> [INCOMPLETE][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-dg2-8/igt@gem_exec_ba...@basic.html

  * igt@gem_exec_fence@basic-wait@rcs0:
- bat-dg1-5:  [PASS][8] -> [FAIL][9] +100 other tests fail
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg1-5/igt@gem_exec_fence@basic-w...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-dg1-5/igt@gem_exec_fence@basic-w...@rcs0.html

  * igt@gem_exec_fence@basic-wait@vcs1:
- bat-dg2-8:  NOTRUN -> [FAIL][10] +120 other tests fail
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-dg2-8/igt@gem_exec_fence@basic-w...@vcs1.html

  * igt@gem_sync@basic-each:
- bat-atsm-1: [PASS][11] -> [FAIL][12] +65 other tests fail
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-atsm-1/igt@gem_s...@basic-each.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-atsm-1/igt@gem_s...@basic-each.html

  * igt@gem_wait@busy@all-engines:
- fi-skl-guc: [PASS][13] -> [FAIL][14] +1 other test fail
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-skl-guc/igt@gem_wait@b...@all-engines.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/fi-skl-guc/igt@gem_wait@b...@all-engines.html
- fi-kbl-x1275:   [PASS][15] -> [FAIL][16] +1 other test fail
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-kbl-x1275/igt@gem_wait@b...@all-engines.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/fi-kbl-x1275/igt@gem_wait@b...@all-engines.html
- bat-adln-1: [PASS][17] -> [FAIL][18] +1 other test fail
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-adln-1/igt@gem_wait@b...@all-engines.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/bat-adln-1/igt@gem_wait@b...@all-engines.html
- fi-kbl-8809g:   [PASS][19] -> [FAIL][20] +1 other test fail
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-kbl-8809g/igt@gem_wait@b...@all-engines.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/fi-kbl-8809g/igt@gem_wait@b...@all-engines.html
- fi-ivb-3770:[PASS][21] -> [FAIL][22] +1 other test fail
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-ivb-3770/igt@gem_wait@b...@all-engines.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/fi-ivb-3770/igt@gem_wait@b...@all-engines.html
- fi-elk-e7500:   [PASS][23] -> [FAIL][24] +1 other test fail
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-elk-e7500/igt@gem_wait@b...@all-engines.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124016v1/fi-elk-e7500/igt@gem_wait@b...@all-engines.htm

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Allow users to disable waitboost

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: Allow users to disable waitboost
URL   : https://patchwork.freedesktop.org/series/124016/
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.CHECKPATCH: warning for drm/i915/gem: Allow users to disable waitboost

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915/gem: Allow users to disable waitboost
URL   : https://patchwork.freedesktop.org/series/124016/
State : warning

== Summary ==

Error: dim checkpatch failed
3bc405ff6c90 drm/i915/gem: Allow users to disable waitboost
-:85: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#85: FILE: include/uapi/drm/i915_drm.h:1931:
+#define I915_GEM_WAITBOOST_DISABLE  (1u<<0)
^

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




[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/edid: Fixup h/vsync_end instead of h/vtotal

2023-09-20 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/edid: Fixup h/vsync_end instead of 
h/vtotal
URL   : https://patchwork.freedesktop.org/series/124014/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13659 -> Patchwork_124014v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-mtlp-8: NOTRUN -> [ABORT][1] ([i915#9262])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124014v1/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][2] ([i915#6645])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124014v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [DMESG-FAIL][3] ([i915#5334]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124014v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
- bat-dg2-11: [INCOMPLETE][5] ([i915#7609] / [i915#7913]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124014v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [ABORT][7] ([i915#9262]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124014v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html

  * igt@kms_chamelium_edid@hdmi-edid-read:
- {bat-dg2-13}:   [DMESG-WARN][9] ([i915#7952]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124014v1/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html

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

  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7952]: https://gitlab.freedesktop.org/drm/intel/issues/7952
  [i915#9262]: https://gitlab.freedesktop.org/drm/intel/issues/9262


Build changes
-

  * Linux: CI_DRM_13659 -> Patchwork_124014v1

  CI-20190529: 20190529
  CI_DRM_13659: b64f074fa9711dea043833b2d0990d1a4f7a36ac @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7494: 8b5be5770319f47d71782bc89e4738aa63d6906d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_124014v1: b64f074fa9711dea043833b2d0990d1a4f7a36ac @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

c88ce97174b1 drm/i915/bios: Fixup h/vsync_end instead of h/vtotal
11f93a4aa0ee drm/edid: Fixup h/vsync_end instead of h/vtotal

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/edid: Fixup h/vsync_end instead of h/vtotal

2023-09-20 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/edid: Fixup h/vsync_end instead of 
h/vtotal
URL   : https://patchwork.freedesktop.org/series/124014/
State : warning

== Summary ==

Error: dim checkpatch failed
914b05588bae drm/edid: Fixup h/vsync_end instead of h/vtotal
-:20: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line 
(possible unwrapped commit description?)
#20: 
https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245

total: 0 errors, 1 warnings, 0 checks, 24 lines checked
974fd9b24154 drm/i915/bios: Fixup h/vsync_end instead of h/vtotal




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/edid: Fixup h/vsync_end instead of h/vtotal

2023-09-20 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/edid: Fixup h/vsync_end instead of 
h/vtotal
URL   : https://patchwork.freedesktop.org/series/124014/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced 
symbol 'mask'
+./include/asm-g

[Intel-gfx] ✓ Fi.CI.BAT: success for Apply Wa_16018031267 / Wa_16018063123

2023-09-20 Thread Patchwork
== Series Details ==

Series: Apply Wa_16018031267 / Wa_16018063123
URL   : https://patchwork.freedesktop.org/series/124011/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13659 -> Patchwork_124011v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 40)
--

  Additional (1): bat-dg2-8 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-mtlp-8: NOTRUN -> [ABORT][1] ([i915#9262])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html

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

  * igt@gem_mmap_gtt@basic:
- bat-dg2-8:  NOTRUN -> [SKIP][3] ([i915#4077]) +2 other tests skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@gem_mmap_...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg2-8:  NOTRUN -> [SKIP][4] ([i915#4079]) +1 other test skip
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@gem_tiled_pread_basic.html

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

  * igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#6645])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
- bat-dg2-8:  NOTRUN -> [SKIP][7] ([i915#6645])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][8] ([i915#5190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][9] ([i915#4215] / [i915#5190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_addfb_ba...@basic-y-tiled-legacy.html

  * igt@kms_addfb_basic@framebuffer-vs-set-tiling:
- bat-dg2-8:  NOTRUN -> [SKIP][10] ([i915#4212]) +6 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg2-8:  NOTRUN -> [SKIP][11] ([i915#4212] / [i915#5608])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_addfb_ba...@tile-pitch-mismatch.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg2-8:  NOTRUN -> [SKIP][12] ([i915#4103] / [i915#4213] / 
[i915#5608]) +1 other test skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-dg2-8:  NOTRUN -> [SKIP][13] ([fdo#109285])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_force_connector_basic@prune-stale-modes:
- bat-dg2-8:  NOTRUN -> [SKIP][14] ([i915#5274])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_force_connector_ba...@prune-stale-modes.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][15] ([i915#3546]) +2 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_psr@cursor_plane_move:
- bat-dg2-8:  NOTRUN -> [SKIP][16] ([i915#1072]) +3 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_psr@cursor_plane_move.html

  * igt@kms_setmode@basic-clone-single-crtc:
- bat-dg2-8:  NOTRUN -> [SKIP][17] ([i915#3555])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@kms_setm...@basic-clone-single-crtc.html

  * igt@prime_vgem@basic-fence-flip:
- bat-dg2-8:  NOTRUN -> [SKIP][18] ([i915#3708])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124011v1/bat-dg2-8/igt@prime_v...@basic-fence-flip.html

  * igt@prime_vgem@basic-fence-mmap:
- bat-dg2-8:  N

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Apply Wa_16018031267 / Wa_16018063123

2023-09-20 Thread Patchwork
== Series Details ==

Series: Apply Wa_16018031267 / Wa_16018063123
URL   : https://patchwork.freedesktop.org/series/124011/
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.CHECKPATCH: warning for Apply Wa_16018031267 / Wa_16018063123

2023-09-20 Thread Patchwork
== Series Details ==

Series: Apply Wa_16018031267 / Wa_16018063123
URL   : https://patchwork.freedesktop.org/series/124011/
State : warning

== Summary ==

Error: dim checkpatch failed
9cb3de2b89cf drm/i915: Enable NULL PTE support for vm scratch
-:8: WARNING:TYPO_SPELLING: 'teh' may be misspelled - perhaps 'the'?
#8: 
The use of NULL PTEs in teh vm scratch pages requires us to change how
^^^

total: 0 errors, 1 warnings, 0 checks, 57 lines checked
f052b245654b drm/i915: Reserve some kernel space per vm
-:31: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#31: FILE: drivers/gpu/drm/i915/gt/gen8_ppgtt.c:1021:
+   GEM_BUG_ON(drm_mm_reserve_node(&ppgtt->vm.mm, &ppgtt->vm.rsvd));

total: 0 errors, 1 warnings, 0 checks, 26 lines checked
7516e857852c drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
-:10: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do 
not match
#10: 
Co-developed-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt 

-:35: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine' - possible 
side-effects?
#35: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:86:
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+   IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+   engine->class == COPY_ENGINE_CLASS)

-:35: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'engine' may be better as 
'(engine)' to avoid precedence issues
#35: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:86:
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+   IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+   engine->class == COPY_ENGINE_CLASS)

-:68: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#68: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:836:
+   GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);

-:183: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#183: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1498:
+   GEM_BUG_ON(cs - start > I915_GTT_PAGE_SIZE / sizeof(*cs));

total: 0 errors, 3 warnings, 2 checks, 316 lines checked
c746aedcd052 drm/i915: Set copy engine arbitration for Wa_16018031267 / 
Wa_16018063123




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)
URL   : https://patchwork.freedesktop.org/series/124004/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13659 -> Patchwork_124004v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 40)
--

  Additional (1): fi-kbl-soraka 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: NOTRUN -> [DMESG-FAIL][4] ([i915#7699] / [i915#7913])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124004v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@kms_dsc@dsc-basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271]) +9 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124004v1/fi-kbl-soraka/igt@kms_...@dsc-basic.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg2-9:  [INCOMPLETE][6] ([i915#8797] / [i915#9275]) -> 
[PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124004v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [DMESG-FAIL][8] ([i915#5334]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124004v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
- bat-dg2-11: [INCOMPLETE][10] ([i915#7609] / [i915#7913]) -> 
[PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124004v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][12] ([i915#8668]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124004v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#8797]: https://gitlab.freedesktop.org/drm/intel/issues/8797
  [i915#9275]: https://gitlab.freedesktop.org/drm/intel/issues/9275


Build changes
-

  * Linux: CI_DRM_13659 -> Patchwork_124004v1

  CI-20190529: 20190529
  CI_DRM_13659: b64f074fa9711dea043833b2d0990d1a4f7a36ac @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7494: 8b5be5770319f47d71782bc89e4738aa63d6906d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_124004v1: b64f074fa9711dea043833b2d0990d1a4f7a36ac @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

ba4e41802d45 drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)
ac5b199372b3 drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on 
Lenovo Yoga Tab 3 (v2)
01e25c75a0ea drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size 
on Lenovo Yoga Tablet 2 series

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)
URL   : https://patchwork.freedesktop.org/series/124004/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced 
symbol 'val'
+./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/irq: Clear GFX_MSTR_IRQ as part of IRQ reset (rev2)

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915/irq: Clear GFX_MSTR_IRQ as part of IRQ reset (rev2)
URL   : https://patchwork.freedesktop.org/series/123928/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13659 -> Patchwork_123928v2


Summary
---

  **FAILURE**

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

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

Participating hosts (40 -> 39)
--

  Additional (1): fi-kbl-soraka 
  Missing(2): fi-hsw-4770 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@perf:
- fi-kbl-soraka:  NOTRUN -> [ABORT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123928v2/fi-kbl-soraka/igt@i915_selftest@l...@perf.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@kms_dsc@dsc-basic:
- fi-kbl-soraka:  NOTRUN -> [SKIP][5] ([fdo#109271]) +9 other tests skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123928v2/fi-kbl-soraka/igt@kms_...@dsc-basic.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s0@smem:
- bat-dg2-9:  [INCOMPLETE][6] ([i915#8797] / [i915#9275]) -> 
[PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123928v2/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [DMESG-FAIL][8] ([i915#5334]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123928v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_lrc:
- bat-dg2-11: [INCOMPLETE][10] ([i915#7609] / [i915#7913]) -> 
[PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123928v2/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html

  * igt@kms_chamelium_edid@hdmi-edid-read:
- {bat-dg2-13}:   [DMESG-WARN][12] ([i915#7952]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123928v2/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][14] ([i915#8668]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13659/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123928v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7952]: https://gitlab.freedesktop.org/drm/intel/issues/7952
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915

[Intel-gfx] [PATCH] drm/i915/display/dp: Change DSC vs lower bpp priority

2023-09-20 Thread Charlton Lin
Previously driver would lower bpp before trying DSC. Monitors
capable of acheiving highest mode with either DSC or lower bpp
would have bpp dropped instead of attempting DSC at higher bpp.

Changed the order in which driver attempts DSC and lower bpp.
Attempt DSC before trying lower bpp without DSC.

Cc: Ankit Nautiyal 
Cc: Suraj Kandpal 
Cc: Khaled Almahallawy 
Signed-off-by: Charlton Lin 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2206b45bc78c..0d65ca4085b4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1527,12 +1527,14 @@ static int
 intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
  struct intel_crtc_state *pipe_config,
  const struct drm_connector_state *conn_state,
- const struct link_config_limits *limits)
+ const struct link_config_limits *limits,
+ bool allow_bpp_change)
 {
int bpp, i, lane_count, clock = intel_dp_mode_clock(pipe_config, 
conn_state);
int mode_rate, link_rate, link_avail;
+   int min_bpp = allow_bpp_change ? limits->min_bpp : limits->max_bpp;
 
-   for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+   for (bpp = limits->max_bpp; bpp >= min_bpp; bpp -= 2 * 3) {
int link_bpp = intel_dp_output_bpp(pipe_config->output_format, 
bpp);
 
mode_rate = intel_dp_link_required(clock, link_bpp);
@@ -2247,7 +2249,8 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
 * Optimize for slow and wide for everything, because there are some
 * eDP 1.3 and 1.4 panels don't work well with fast and narrow.
 */
-   ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, 
conn_state, &limits);
+   ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config,
+   conn_state, &limits, false);
 
if (ret || joiner_needs_dsc || intel_dp->force_dsc_en) {
drm_dbg_kms(&i915->drm, "Try DSC (fallback=%s, joiner=%s, 
force=%s)\n",
@@ -2255,10 +2258,16 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
str_yes_no(intel_dp->force_dsc_en));
ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
  conn_state, &limits, 64, 
true);
-   if (ret < 0)
-   return ret;
}
 
+   if (ret < 0)
+   ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config,
+   conn_state, &limits,
+   true);
+
+   if (ret < 0)
+   return ret;
+
if (pipe_config->dsc.compression_enable) {
drm_dbg_kms(&i915->drm,
"DP lane count %d clock %d Input bpp %d Compressed 
bpp %d\n",
-- 
2.25.1



[Intel-gfx] [PATCH] drm/i915/gem: Allow users to disable waitboost

2023-09-20 Thread Vinay Belgaumkar
Provide a bit to disable waitboost while waiting on a gem object.
Waitboost results in increased power consumption by requesting RP0
while waiting for the request to complete. Add a bit in the gem_wait()
IOCTL where this can be disabled.

This is related to the libva API change here -
Link: 
https://github.com/XinfengZhang/libva/commit/3d90d18c67609a73121bb71b20ee4776b54b61a7

Cc: Rodrigo Vivi 
Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gem/i915_gem_wait.c | 9 ++---
 drivers/gpu/drm/i915/i915_request.c  | 3 ++-
 drivers/gpu/drm/i915/i915_request.h  | 1 +
 include/uapi/drm/i915_drm.h  | 1 +
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c 
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index d4b918fb11ce..955885ec859d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -72,7 +72,8 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
struct dma_fence *fence;
long ret = timeout ?: 1;
 
-   i915_gem_object_boost(resv, flags);
+   if (!(flags & I915_WAITBOOST_DISABLE))
+   i915_gem_object_boost(resv, flags);
 
dma_resv_iter_begin(&cursor, resv,
dma_resv_usage_rw(flags & I915_WAIT_ALL));
@@ -236,7 +237,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
ktime_t start;
long ret;
 
-   if (args->flags != 0)
+   if (args->flags != 0 || args->flags != I915_GEM_WAITBOOST_DISABLE)
return -EINVAL;
 
obj = i915_gem_object_lookup(file, args->bo_handle);
@@ -248,7 +249,9 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
ret = i915_gem_object_wait(obj,
   I915_WAIT_INTERRUPTIBLE |
   I915_WAIT_PRIORITY |
-  I915_WAIT_ALL,
+  I915_WAIT_ALL |
+  (args->flags & I915_GEM_WAITBOOST_DISABLE ?
+   I915_WAITBOOST_DISABLE : 0),
   to_wait_timeout(args->timeout_ns));
 
if (args->timeout_ns > 0) {
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index f59081066a19..2957409b4b2a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -2044,7 +2044,8 @@ long i915_request_wait_timeout(struct i915_request *rq,
 * but at a cost of spending more power processing the workload
 * (bad for battery).
 */
-   if (flags & I915_WAIT_PRIORITY && !i915_request_started(rq))
+   if (!(flags & I915_WAITBOOST_DISABLE) && (flags & I915_WAIT_PRIORITY) &&
+   !i915_request_started(rq))
intel_rps_boost(rq);
 
wait.tsk = current;
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 0ac55b2e4223..3cc00e8254dc 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -445,6 +445,7 @@ long i915_request_wait(struct i915_request *rq,
 #define I915_WAIT_INTERRUPTIBLEBIT(0)
 #define I915_WAIT_PRIORITY BIT(1) /* small priority bump for the request */
 #define I915_WAIT_ALL  BIT(2) /* used by i915_gem_object_wait() */
+#define I915_WAITBOOST_DISABLE BIT(3) /* used by i915_gem_object_wait() */
 
 void i915_request_show(struct drm_printer *m,
   const struct i915_request *rq,
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 7000e5910a1d..4adee70e39cf 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1928,6 +1928,7 @@ struct drm_i915_gem_wait {
/** Handle of BO we shall wait on */
__u32 bo_handle;
__u32 flags;
+#define I915_GEM_WAITBOOST_DISABLE  (1u<<0)
/** Number of nanoseconds to wait, Returns time remaining. */
__s64 timeout_ns;
 };
-- 
2.38.1



[Intel-gfx] [PATCH v2 2/2] drm/i915/bios: Fixup h/vsync_end instead of h/vtotal

2023-09-20 Thread Ville Syrjala
From: Ville Syrjälä 

We have the same h/vsync_end vs. h/vtotal quirk in the VBT parser
that was also present in EDID parser. Adjust the VBT parser the
same way as was done for hte EDID parser to fixup h/vsync_end
instead of h/vtotal. While I'm not currently aware of any machines
that need this for the VBT it seems prudent to keep both parsers
in sync.

And while at it let's add some debugs here as well. A bit
lackluster but didn't feel like plumbing the connector all
the way down at this time.

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

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index f735b035436c..863ff54fffd1 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -521,7 +521,8 @@ static void init_bdb_blocks(struct drm_i915_private *i915,
 }
 
 static void
-fill_detail_timing_data(struct drm_display_mode *panel_fixed_mode,
+fill_detail_timing_data(struct drm_i915_private *i915,
+   struct drm_display_mode *panel_fixed_mode,
const struct lvds_dvo_timing *dvo_timing)
 {
panel_fixed_mode->hdisplay = (dvo_timing->hactive_hi << 8) |
@@ -561,11 +562,17 @@ fill_detail_timing_data(struct drm_display_mode 
*panel_fixed_mode,
panel_fixed_mode->height_mm = (dvo_timing->vimage_hi << 8) |
dvo_timing->vimage_lo;
 
-   /* Some VBTs have bogus h/vtotal values */
-   if (panel_fixed_mode->hsync_end > panel_fixed_mode->htotal)
-   panel_fixed_mode->htotal = panel_fixed_mode->hsync_end + 1;
-   if (panel_fixed_mode->vsync_end > panel_fixed_mode->vtotal)
-   panel_fixed_mode->vtotal = panel_fixed_mode->vsync_end + 1;
+   /* Some VBTs have bogus h/vsync_end values */
+   if (panel_fixed_mode->hsync_end > panel_fixed_mode->htotal) {
+   drm_dbg_kms(&i915->drm, "reducing hsync_end %d->%d\n",
+   panel_fixed_mode->hsync_end, 
panel_fixed_mode->htotal);
+   panel_fixed_mode->hsync_end = panel_fixed_mode->htotal;
+   }
+   if (panel_fixed_mode->vsync_end > panel_fixed_mode->vtotal) {
+   drm_dbg_kms(&i915->drm, "reducing vsync_end %d->%d\n",
+   panel_fixed_mode->vsync_end, 
panel_fixed_mode->vtotal);
+   panel_fixed_mode->vsync_end = panel_fixed_mode->vtotal;
+   }
 
drm_mode_set_name(panel_fixed_mode);
 }
@@ -849,7 +856,7 @@ parse_lfp_panel_dtd(struct drm_i915_private *i915,
if (!panel_fixed_mode)
return;
 
-   fill_detail_timing_data(panel_fixed_mode, panel_dvo_timing);
+   fill_detail_timing_data(i915, panel_fixed_mode, panel_dvo_timing);
 
panel->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
 
@@ -1134,7 +1141,7 @@ parse_sdvo_panel_data(struct drm_i915_private *i915,
if (!panel_fixed_mode)
return;
 
-   fill_detail_timing_data(panel_fixed_mode, &dtds->dtds[index]);
+   fill_detail_timing_data(i915, panel_fixed_mode, &dtds->dtds[index]);
 
panel->vbt.sdvo_lvds_vbt_mode = panel_fixed_mode;
 
-- 
2.41.0



[Intel-gfx] [PATCH v2 1/2] drm/edid: Fixup h/vsync_end instead of h/vtotal

2023-09-20 Thread Ville Syrjala
From: Ville Syrjälä 

There are some weird EDIDs floating around that have the sync
pulse extending beyond the end of the blanking period.

On the currently problemtic machine (HP Omni 120) EDID reports
the following mode:
"1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
which is then "corrected" to have htotal=1861 by the current drm_edid.c
code.

The fixup code was originally added in commit 7064fef56369 ("drm: work
around EDIDs with bad htotal/vtotal values"). Googling around we end up in
https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245
where we find an EDID for a Dell Studio 15, which reports:
(II) VESA(0): clock: 65.0 MHz   Image Size:  331 x 207 mm
(II) VESA(0): h_active: 1280  h_sync: 1328  h_sync_end 1360 h_blank_end 1337 
h_border: 0
(II) VESA(0): v_active: 800  v_sync: 803  v_sync_end 809 v_blanking: 810 
v_border: 0

Note that if we use the hblank size (as opposed of the hsync_end)
from the DTD to determine htotal we get exactly 60Hz refresh rate in
both cases, whereas using hsync_end to determine htotal we get a
slightly lower refresh rates. This makes me believe the using the
hblank size is what was intended even in those cases.

Also note that in case of the HP Onmi 120 the VBIOS boots with these:
  crtc timings: 108000 1600 1780 1860 1800 900 910 913 1000, type: 0x40 flags: 
0x5
ie. it just blindly stuffs the bogus hsync_end and htotal from the DTD
into the transcoder timing registers, and the display works. I believe
the (at least more modern) hardware will automagically terminate the hsync
pulse when the timing generator reaches htotal, which again points that we
should use the hblank size to determine htotal. Unfortunatley the old bug
reports for the Dell machines are extremely lacking in useful details so
we have no idea what kind of timings the VBIOS programmed into the
hardware :(

Let's just flip this quirk around and reduce the length of the sync
pulse instead of extending the blanking period. This at least seems
to be the correct thing to do on more modern hardware. And if any
issues crop up on older hardware we need to debug them properly.

v2: Add debug message breadcrumbs (Jani)

Reviewed-by: Jani Nikula  #v1
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8895
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 39dd3f694544..ec1cb4890acb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3497,11 +3497,19 @@ static struct drm_display_mode 
*drm_mode_detailed(struct drm_connector *connecto
mode->vsync_end = mode->vsync_start + vsync_pulse_width;
mode->vtotal = mode->vdisplay + vblank;
 
-   /* Some EDIDs have bogus h/vtotal values */
-   if (mode->hsync_end > mode->htotal)
-   mode->htotal = mode->hsync_end + 1;
-   if (mode->vsync_end > mode->vtotal)
-   mode->vtotal = mode->vsync_end + 1;
+   /* Some EDIDs have bogus h/vsync_end values */
+   if (mode->hsync_end > mode->htotal) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] reducing hsync_end 
%d->%d\n",
+   connector->base.id, connector->name,
+   mode->hsync_end, mode->htotal);
+   mode->hsync_end = mode->htotal;
+   }
+   if (mode->vsync_end > mode->vtotal) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] reducing vsync_end 
%d->%d\n",
+   connector->base.id, connector->name,
+   mode->vsync_end, mode->vtotal);
+   mode->vsync_end = mode->vtotal;
+   }
 
drm_mode_do_interlace_quirk(mode, pt);
 
-- 
2.41.0



[Intel-gfx] [PATCH v12 3/4] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123

2023-09-20 Thread Jonathan Cavitt
Apply WABB blit for Wa_16018031267 / Wa_16018063123.
Additionally, update the lrc selftest to exercise the new
WABB changes.

Co-developed-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt 
---
 drivers/gpu/drm/i915/gt/intel_engine_regs.h |   3 +
 drivers/gpu/drm/i915/gt/intel_gt.h  |   4 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h|   2 +
 drivers/gpu/drm/i915/gt/intel_lrc.c | 100 +++-
 drivers/gpu/drm/i915/gt/selftest_lrc.c  |  65 +
 5 files changed, 153 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index fdd4ddd3a978a..b8618ee3e3041 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -118,6 +118,9 @@
 #define   CCID_EXTENDED_STATE_RESTORE  BIT(2)
 #define   CCID_EXTENDED_STATE_SAVE BIT(3)
 #define RING_BB_PER_CTX_PTR(base)  _MMIO((base) + 0x1c0) /* gen8+ 
*/
+#define   PER_CTX_BB_FORCE BIT(2)
+#define   PER_CTX_BB_VALID BIT(0)
+
 #define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4) 
/* gen8+ */
 #define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ 
*/
 #define ECOSKPD(base)  _MMIO((base) + 0x1d0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 239848bcb2a42..40cc0005dd735 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -83,6 +83,10 @@ struct drm_printer;
  ##__VA_ARGS__);   \
 } while (0)
 
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+   IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+   engine->class == COPY_ENGINE_CLASS)
+
 static inline bool gt_is_root(struct intel_gt *gt)
 {
return !gt->info.id;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index def7dd0eb6f19..4917633f299dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -307,6 +307,8 @@ enum intel_gt_scratch_field {
 
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
+
+   INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT = 384,
 };
 
 #define intel_gt_support_legacy_fencing(gt) ((gt)->ggtt->num_fences > 0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index eaf66d9031665..db7088abeef38 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct 
intel_engine_cs *engine)
return 0;
 }
 
+static void
+lrc_setup_bb_per_ctx(u32 *regs,
+const struct intel_engine_cs *engine,
+u32 ctx_bb_ggtt_addr)
+{
+   GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
+   regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
+   ctx_bb_ggtt_addr |
+   PER_CTX_BB_FORCE |
+   PER_CTX_BB_VALID;
+}
+
 static void
 lrc_setup_indirect_ctx(u32 *regs,
   const struct intel_engine_cs *engine,
@@ -1020,7 +1032,13 @@ static u32 context_wa_bb_offset(const struct 
intel_context *ce)
return PAGE_SIZE * ce->wa_bb_page;
 }
 
-static u32 *context_indirect_bb(const struct intel_context *ce)
+/*
+ * per_ctx below determines which WABB section is used.
+ * When true, the function returns the location of the
+ * PER_CTX_BB.  When false, the function returns the
+ * location of the INDIRECT_CTX.
+ */
+static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
 {
void *ptr;
 
@@ -1029,6 +1047,7 @@ static u32 *context_indirect_bb(const struct 
intel_context *ce)
ptr = ce->lrc_reg_state;
ptr -= LRC_STATE_OFFSET; /* back to start of context image */
ptr += context_wa_bb_offset(ce);
+   ptr += per_ctx ? PAGE_SIZE : 0;
 
return ptr;
 }
@@ -1105,7 +1124,8 @@ __lrc_alloc_state(struct intel_context *ce, struct 
intel_engine_cs *engine)
 
if (GRAPHICS_VER(engine->i915) >= 12) {
ce->wa_bb_page = context_size / PAGE_SIZE;
-   context_size += PAGE_SIZE;
+   /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
+   context_size += PAGE_SIZE * 2;
}
 
if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {
@@ -1407,12 +1427,85 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context 
*ce, u32 *cs)
return gen12_emit_aux_table_inv(ce->engine, cs);
 }
 
+static u32 *xehp_emit_fastcolor_blt_wabb(const struct intel_context *ce, u32 
*cs)
+{
+   struct intel_gt *gt = ce->engine->gt;
+   int mocs = gt->mocs.uc_index << 1;
+
+   /**
+* Wa_16018031267 / Wa_16018063123 requires that SW forces the
+* main copy engine arbitration into round robin mode.  We
+*

[Intel-gfx] [PATCH v12 4/4] drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123

2023-09-20 Thread Jonathan Cavitt
Set copy engine arbitration into round robin mode
for part of Wa_16018031267 / Wa_16018063123 mitigation.

Signed-off-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt 
---
 drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +++
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h 
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index b8618ee3e3041..c0c8c12edea10 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -124,6 +124,9 @@
 #define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4) 
/* gen8+ */
 #define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ 
*/
 #define ECOSKPD(base)  _MMIO((base) + 0x1d0)
+#define   XEHP_BLITTER_SCHEDULING_MODE_MASKREG_GENMASK(12, 11)
+#define   XEHP_BLITTER_ROUND_ROBIN_MODE\
+   REG_FIELD_PREP(XEHP_BLITTER_SCHEDULING_MODE_MASK, 1)
 #define   ECO_CONSTANT_BUFFER_SR_DISABLE   REG_BIT(4)
 #define   ECO_GATING_CX_ONLY   REG_BIT(3)
 #define   GEN6_BLITTER_FBC_NOTIFY  REG_BIT(3)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 660d4f358eab7..b8f3b991e4202 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2781,6 +2781,11 @@ xcs_engine_wa_init(struct intel_engine_cs *engine, 
struct i915_wa_list *wal)
 RING_SEMA_WAIT_POLL(engine->mmio_base),
 1);
}
+   /* Wa_16018031267, Wa_16018063123 */
+   if (NEEDS_FASTCOLOR_BLT_WABB(engine))
+   wa_masked_field_set(wal, ECOSKPD(engine->mmio_base),
+   XEHP_BLITTER_SCHEDULING_MODE_MASK,
+   XEHP_BLITTER_ROUND_ROBIN_MODE);
 }
 
 static void
-- 
2.25.1



[Intel-gfx] [PATCH v12 1/4] drm/i915: Enable NULL PTE support for vm scratch

2023-09-20 Thread Jonathan Cavitt
Enable NULL PTE support for vm scratch pages.

The use of NULL PTEs in teh vm scratch pages requires us to change how
the i915 gem_contexts live selftest perform vm_isolation: instead of
checking the scratch pages are isolated and don't affect each other, we
check that all changes to the scratch pages are voided.

Signed-off-by: Jonathan Cavitt 
Suggested-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 ++
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  | 3 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h   | 1 +
 drivers/gpu/drm/i915/i915_drv.h   | 2 ++
 drivers/gpu/drm/i915/i915_pci.c   | 2 ++
 drivers/gpu/drm/i915/intel_device_info.h  | 1 +
 6 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 7021b6e9b219e..48fc5990343bc 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1751,6 +1751,12 @@ static int check_scratch_page(struct i915_gem_context 
*ctx, u32 *out)
if (!vm)
return -ENODEV;
 
+   if (HAS_NULL_PAGE(vm->i915)) {
+   if (out)
+   *out = 0;
+   return 0;
+   }
+
if (!vm->scratch[0]) {
pr_err("No scratch page!\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 9895e18df0435..84aa29715e0ac 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -855,6 +855,9 @@ static int gen8_init_scratch(struct i915_address_space *vm)
  I915_CACHE_NONE),
   pte_flags);
 
+   if (HAS_NULL_PAGE(vm->i915))
+   vm->scratch[0]->encode |= PTE_NULL_PAGE;
+
for (i = 1; i <= vm->top; i++) {
struct drm_i915_gem_object *obj;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 346ec8ec2edda..153ddfca0ae18 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -151,6 +151,7 @@ typedef u64 gen8_pte_t;
 
 #define GEN8_PAGE_PRESENT  BIT_ULL(0)
 #define GEN8_PAGE_RW   BIT_ULL(1)
+#define PTE_NULL_PAGE  BIT_ULL(9)
 
 #define GEN8_PDE_IPS_64K BIT(11)
 #define GEN8_PDE_PS_2M   BIT(7)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 87ffc477c3b1a..687a8fcdc3d54 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -782,6 +782,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
  */
 #define HAS_FLAT_CCS(i915)   (INTEL_INFO(i915)->has_flat_ccs)
 
+#define HAS_NULL_PAGE(dev_priv) (INTEL_INFO(dev_priv)->has_null_page)
+
 #define HAS_GT_UC(i915)(INTEL_INFO(i915)->has_gt_uc)
 
 #define HAS_POOLED_EU(i915)(RUNTIME_INFO(i915)->has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index df7c261410f79..80a65ea192107 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -642,6 +642,7 @@ static const struct intel_device_info jsl_info = {
GEN(12), \
TGL_CACHELEVEL, \
.has_global_mocs = 1, \
+   .has_null_page = 1, \
.has_pxp = 1, \
.max_pat_index = 3
 
@@ -721,6 +722,7 @@ static const struct intel_device_info adl_p_info = {
.has_mslice_steering = 1, \
.has_oa_bpc_reporting = 1, \
.has_oa_slice_contrib_limits = 1, \
+   .has_null_page = 1, \
.has_oam = 1, \
.has_rc6 = 1, \
.has_reset_engine = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 39817490b13fd..252f8dc0fe790 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -162,6 +162,7 @@ enum intel_ppgtt_type {
func(has_mslice_steering); \
func(has_oa_bpc_reporting); \
func(has_oa_slice_contrib_limits); \
+   func(has_null_page); \
func(has_oam); \
func(has_one_eu_per_fuse_bit); \
func(has_pxp); \
-- 
2.25.1



[Intel-gfx] [PATCH v12 2/4] drm/i915: Reserve some kernel space per vm

2023-09-20 Thread Jonathan Cavitt
Reserve two pages in each vm for kernel space to use for things
such as workarounds.

Signed-off-by: Jonathan Cavitt 
Suggested-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 7 +++
 drivers/gpu/drm/i915/gt/intel_gtt.h  | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 84aa29715e0ac..6344d733fb2c4 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -230,6 +230,7 @@ static void gen8_ppgtt_cleanup(struct i915_address_space 
*vm)
 gen8_pd_top_count(vm), vm->top);
 
free_scratch(vm);
+   drm_mm_remove_node(&vm->rsvd);
 }
 
 static u64 __gen8_ppgtt_clear(struct i915_address_space * const vm,
@@ -1014,6 +1015,12 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
ppgtt->vm.foreach = gen8_ppgtt_foreach;
ppgtt->vm.cleanup = gen8_ppgtt_cleanup;
 
+   ppgtt->vm.rsvd.start = ppgtt->vm.total - (SZ_4K * 2);
+   ppgtt->vm.rsvd.size = (SZ_4K * 2);
+   ppgtt->vm.rsvd.color = I915_COLOR_UNEVICTABLE;
+   GEM_BUG_ON(drm_mm_reserve_node(&ppgtt->vm.mm, &ppgtt->vm.rsvd));
+   ppgtt->vm.total -= (SZ_4K * 2);
+
err = gen8_init_scratch(&ppgtt->vm);
if (err)
goto err_put;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 153ddfca0ae18..680ce27dda40c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -247,6 +247,7 @@ struct i915_address_space {
struct work_struct release_work;
 
struct drm_mm mm;
+   struct drm_mm_node rsvd;
struct intel_gt *gt;
struct drm_i915_private *i915;
struct device *dma;
-- 
2.25.1



[Intel-gfx] [PATCH v12 0/4] Apply Wa_16018031267 / Wa_16018063123

2023-09-20 Thread Jonathan Cavitt
Apply Wa_16018031267 / Wa_16018063123.  This necessitates submitting a
fastcolor blit as WABB and setting the copy engine arbitration to
round-robin mode.

v2:
- Rename old platform check in second patch to match
  declaration in first patch.
- Refactor second patch name to match first patch.

v3:
- Move NEEDS_FASTCOLOR_BLT_WABB to intel_gt.h.
- Refactor NEEDS_FASTCOLOR_BLT_WABB to make it more
  streamlined to use.
- Stop dividing PAGE_SIZE by sizeof(u32) when computing
  ctx_bb_ggtt_addr for lrc_setup_bb_per_ctx.
- Reduce comment complexity.
- Fix several checkpatch warnings.

v4:
- Actually stop dividing PAGE_SIZE by sizeof(u32) when
  computing ctx_bb_ggtt_addr for lrc_setup_bb_per_ctx.

v5:
- Stop dividing PAGE_SIZE by sizeof(u32) in
  check_ring_start during lrc live selftest.

v6:
- Append MI_BATCH_BUFFER_END to end of all PER_CTX_BB
  command streams.
- No longer skip on empty, as command stream will never
  be empty (always contains at least MI_BATCH_BUFFER_END).
- No longer append MI_NOOP until cachline aligned (was a
  fragment from INDIRECT_CTX setup).

v7:
- Use 0x6b instead of 0 for color to maintain functionality.

v8:
- Revert v7.
- Add some reserved kernel space per vm to run the
  workaround on.

v9:
- Hide reserved kernel space per vm from userspace.

v10:
- Revert v7 properly.
- Test on updated IGT.

v11:
- Remove Test-with tag.
- Reserve two pages per vm for workaround.

v12:
- Use Null page for scratch page.

Signed-off-by: Nirmoy Das 
Signed-off-by: Jonathan Cavitt 
CC: Joonas Lahtinen 
CC: Rodrigo Vivi 
CC: Tomasz Mistat 
CC: Gregory F Germano 
CC: Matt Roper 
CC: James Ausmus 
CC: Chris Wilson 
CC: Andi Shyti 

Jonathan Cavitt (4):
  drm/i915: Enable NULL PTE support for vm scratch
  drm/i915: Reserve some kernel space per vm
  drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
  drm/i915: Set copy engine arbitration for Wa_16018031267 /
Wa_16018063123

 .../drm/i915/gem/selftests/i915_gem_context.c |   6 ++
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  10 ++
 drivers/gpu/drm/i915/gt/intel_engine_regs.h   |   6 ++
 drivers/gpu/drm/i915/gt/intel_gt.h|   4 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   2 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 100 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   |   5 +
 drivers/gpu/drm/i915/gt/selftest_lrc.c|  65 
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_pci.c   |   2 +
 drivers/gpu/drm/i915/intel_device_info.h  |   1 +
 12 files changed, 184 insertions(+), 21 deletions(-)

-- 
2.25.1



Re: [Intel-gfx] [PATCH v2] drm/i915: refactor deprecated strncpy

2023-09-20 Thread Rodrigo Vivi
On Tue, Sep 19, 2023 at 04:45:31AM +, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
> 
> We should prefer more robust and less ambiguous string interfaces.
> 
> A suitable replacement is `strscpy` [2] due to the fact that it
> guarantees NUL-termination on the destination buffer without
> unnecessarily NUL-padding. `ctx` is zero allocated and as such strncpy's
> NUL-padding behavior was strictly a performance hit which is now
> resolved.
> 
> Link: 
> https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
>  [1]
> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html 
> [2]
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger.kernel.org
> Signed-off-by: Justin Stitt 
> ---
> Changes in v2:
> - drop the `... - 1` (thanks Kees)
> - Link to v1: 
> https://lore.kernel.org/r/20230914-strncpy-drivers-gpu-drm-i915-gem-selftests-mock_context-c-v1-1-c3f92df94...@google.com
> ---


Reviewed-by: Rodrigo Vivi 

and pushing it right now to drm-intel-gt-next

>  drivers/gpu/drm/i915/gem/selftests/mock_context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> index 8ac6726ec16b..e199d7dbb876 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
> @@ -36,7 +36,7 @@ mock_context(struct drm_i915_private *i915,
>   if (name) {
>   struct i915_ppgtt *ppgtt;
>  
> - strncpy(ctx->name, name, sizeof(ctx->name) - 1);
> + strscpy(ctx->name, name, sizeof(ctx->name));
>  
>   ppgtt = mock_ppgtt(i915, name);
>   if (!ppgtt)
> 
> ---
> base-commit: 3669558bdf354cd352be955ef2764cde6a9bf5ec
> change-id: 
> 20230914-strncpy-drivers-gpu-drm-i915-gem-selftests-mock_context-c-980c8ecc9142
> 
> Best regards,
> --
> Justin Stitt 
> 


[Intel-gfx] ✓ Fi.CI.BAT: success for Update GGTT with MI_UPDATE_GTT on MTL (rev8)

2023-09-20 Thread Patchwork
== Series Details ==

Series: Update GGTT with MI_UPDATE_GTT on MTL (rev8)
URL   : https://patchwork.freedesktop.org/series/123329/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13658 -> Patchwork_123329v8


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (32 -> 39)
--

  Additional (9): bat-mtlp-8 bat-dg2-9 fi-ilk-650 fi-hsw-4770 fi-glk-j4005 
fi-cfl-8109u fi-pnv-d510 fi-bsw-nick fi-skl-6600u 
  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-hsw-4770:NOTRUN -> [FAIL][1] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-mtlp-8: NOTRUN -> [SKIP][2] ([i915#9318])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html

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

  * igt@gem_lmem_swapping@basic:
- fi-glk-j4005:   NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [SKIP][7] ([fdo#109271]) +18 other tests 
skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html

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

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-8109u:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html
- bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#4613]) +3 other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][11] ([i915#4083])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-dg2-9/igt@gem_m...@basic.html
- bat-mtlp-8: NOTRUN -> [SKIP][12] ([i915#4083])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-mtlp-8/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][13] ([i915#4077]) +2 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-dg2-9/igt@gem_mmap_...@basic.html
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#4077]) +3 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-mtlp-8/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][15] ([i915#4079]) +1 other test skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-dg2-9/igt@gem_render_tiled_bl...@basic.html
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#4079]) +1 other test skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-ilk-650: NOTRUN -> [SKIP][17] ([fdo#109271]) +21 other tests 
skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/fi-ilk-650/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rps@basic-api:
- bat-dg2-9:  NOTRUN -> [SKIP][18] ([i915#6621])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-dg2-9/igt@i915_pm_...@basic-api.html
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#6621])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123329v8/bat-mtlp-8/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: NOTRUN -> [ABORT][20] ([i915#9262])
   [20]: 
ht

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: add a note about fec_enable with 128b/132b

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915: add a note about fec_enable with 128b/132b
URL   : https://patchwork.freedesktop.org/series/123977/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13656_full -> Patchwork_123977v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (9 -> 9)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@flip-vs-suspend@d-edp1:
- shard-mtlp: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/shard-mtlp-1/igt@kms_flip@flip-vs-susp...@d-edp1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-mtlp-4/igt@kms_flip@flip-vs-susp...@d-edp1.html

  * igt@kms_selftest@drm_dp_mst:
- shard-glk:  NOTRUN -> [TIMEOUT][3] +1 other test timeout
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-glk3/igt@kms_selftest@drm_dp_mst.html

  * igt@kms_selftest@drm_plane:
- shard-mtlp: NOTRUN -> [TIMEOUT][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-mtlp-6/igt@kms_selftest@drm_plane.html

  * igt@kms_sequence@get-idle@vga-1-pipe-b:
- shard-snb:  [PASS][5] -> [ABORT][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/shard-snb6/igt@kms_sequence@get-i...@vga-1-pipe-b.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-snb2/igt@kms_sequence@get-i...@vga-1-pipe-b.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@blit-reloc-keep-cache:
- shard-dg2:  NOTRUN -> [SKIP][7] ([i915#8411])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-dg2-7/igt@api_intel...@blit-reloc-keep-cache.html

  * igt@drm_fdinfo@busy-idle-check-all@ccs0:
- shard-mtlp: NOTRUN -> [SKIP][8] ([i915#8414]) +5 other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-mtlp-6/igt@drm_fdinfo@busy-idle-check-...@ccs0.html

  * igt@drm_fdinfo@virtual-idle:
- shard-rkl:  [PASS][9] -> [FAIL][10] ([i915#7742])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/shard-rkl-4/igt@drm_fdi...@virtual-idle.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-rkl-1/igt@drm_fdi...@virtual-idle.html

  * igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-smem-lmem0:
- shard-dg2:  [PASS][11] -> [INCOMPLETE][12] ([i915#7297])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/shard-dg2-1/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-dg2-6/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html

  * igt@gem_ctx_persistence@engines-queued:
- shard-snb:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1099])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-snb2/igt@gem_ctx_persiste...@engines-queued.html

  * igt@gem_ctx_persistence@saturated-hostile-nopreempt@vcs1:
- shard-mtlp: NOTRUN -> [SKIP][14] ([i915#5882]) +5 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-mtlp-6/igt@gem_ctx_persistence@saturated-hostile-nopree...@vcs1.html

  * igt@gem_ctx_sseu@invalid-args:
- shard-mtlp: NOTRUN -> [SKIP][15] ([i915#280])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-mtlp-6/igt@gem_ctx_s...@invalid-args.html

  * igt@gem_exec_balancer@bonded-pair:
- shard-dg2:  NOTRUN -> [SKIP][16] ([i915#4771])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-dg2-1/igt@gem_exec_balan...@bonded-pair.html

  * igt@gem_exec_balancer@bonded-semaphore:
- shard-dg2:  NOTRUN -> [SKIP][17] ([i915#4812])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-dg2-7/igt@gem_exec_balan...@bonded-semaphore.html

  * igt@gem_exec_capture@pi@vcs0:
- shard-mtlp: NOTRUN -> [FAIL][18] ([i915#4475])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/shard-mtlp-2/igt@gem_exec_capture@p...@vcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-rkl:  [PASS][19] -> [FAIL][20] ([i915#2846]

Re: [Intel-gfx] [PATCH 00/10] drm/i915/spi: spi access for discrete graphics

2023-09-20 Thread Winkler, Tomas


> 
> On Wed, Sep 20, 2023 at 01:52:07PM +, Usyskin, Alexander wrote:
> 
> > I've tried to register spi controller with a spi-mem ops, but I can't find 
> > a way
> to connect to mtd subsystem.
> > I took spi-intel as example, which connects to spi-nor but it relies on 
> > JDEC ID
> of flash to configure itself.
> 
> You should use the normal SPI device registration interfaces to register
> whatever devices are connected to the SPI controller.  What in concrete terms
> have you tried to do here and in what way did it not work?

> 
> > We have predefined set of operations unrelated to flash behind the
> controller.
> 
> This sounds like there's some sort of MFD rather than or as well as a flash
> chip, or possibly multiple SPI devices?

Yes, the driver doesn't talk to SPI controller directly it goes via another 
layer, so all SPI standard HW is not accessible, but we wish to expose the MTD 
interface.

Thanks
Tomas



Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Limit the length of an sg list to the requested length

2023-09-20 Thread Andrzej Hajda

On 20.09.2023 14:00, Patchwork wrote:

*Patch Details*
*Series:*   i915: Limit the length of an sg list to the requested length
*URL:*	https://patchwork.freedesktop.org/series/123940/ 


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




  CI Bug Log - changes from CI_DRM_13653_full -> Patchwork_123940v1_full


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_123940v1_full absolutely 
need to be

verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_123940v1_full, please notify your bug team 
(lgci.bug.fil...@intel.com) to allow them

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


Participating hosts (9 -> 9)

No changes in participating hosts


Possible new issues

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



  IGT changes


Possible regressions

  *

igt@drm_mm@drm_mm_test:

  o shard-rkl: NOTRUN -> TIMEOUT





This test always fails (notrun/timeout).


  *

igt@kms_lease@page_flip_implicit_plane@pipe-d-edp-1:

  o shard-mtlp: NOTRUN -> DMESG-FAIL




Re-appearing issue:
https://gitlab.freedesktop.org/drm/intel/-/issues/6955


  *

igt@kms_selftest@drm_damage:

  o shard-dg2: NOTRUN -> TIMEOUT


 +2 other tests timeout
  *

igt@kms_selftest@drm_plane:

  o

shard-snb: NOTRUN -> TIMEOUT


 +1 other test timeout

  o

shard-mtlp: NOTRUN -> TIMEOUT




https://gitlab.freedesktop.org/drm/intel/-/issues/8628



  *

igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:

  o shard-dg2: PASS


 -> INCOMPLETE 




Also seen on CI:
http://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13652/shard-dg2-6/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html



Warnings

  * igt@drm_buddy@drm_buddy_test:
  o shard-apl: ABORT


 -> TIMEOUT 






It also usually timeouts, nothing new.


Summarizing all issues seems unrelated to the patch. If there are no 
objections I will merge it tomorrow.


Regards
Andrzej



Known issues

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



  IGT changes


Issues hit

  *

igt@core_hotunplug@unbind-rebind:

  o shard-snb: NOTRUN -> INCOMPLETE


 (i915#4528  / i915#9372 
)
  *

igt@drm_fdinfo@busy-hang@bcs0:

  o shard-dg2: NOTRUN -> SKIP


 (i915#8414 ) +9 other tests 
skip
  *

igt@drm_fdinfo@virtual-busy-idle:

  o shard-mtlp: NOTRUN -> SKIP


 (i915#8414 )
  *

igt@gem_bad_reloc@negative-reloc-lut:

  o shard-rkl: NOTRUN -> SKIP


 (i915#3281 ) +1 other test skip
  *

igt@gem_ccs@block-multicopy-compressed:

  o shard-tglu: NOTRUN -> SKIP


 (i915#9323 )
  *

igt@gem_close_race@multigpu-basic-threads:

  o

Re: [Intel-gfx] [PATCH 00/12] drm/i915: VRR, LRR, and M/N stuff

2023-09-20 Thread Ville Syrjälä
On Wed, Sep 20, 2023 at 11:54:41AM -0700, Manasi Navare wrote:
> Hi Ville,
> 
> After the comments have been addressed, I have completed reviewing the
> patches. Is there anything
> else blocking this from getting merged? Could we get this merged if
> everything looks good?

Series pushed to drm-intel-next, Thanks for the reviews everyone.

> 
> Regards
> Manasi
> 
> On Fri, Sep 1, 2023 at 6:04 AM Ville Syrjala
>  wrote:
> >
> > From: Ville Syrjälä 
> >
> > Attempt to make VRR, LRR, and M/N updates coexist nicely,
> > allowing fastsets whenever feasible.
> >
> > Lightly smoke tested on my adl.
> >
> > Cc: Manasi Navare 
> >
> > Ville Syrjälä (12):
> >   drm/i915: Move psr unlock out from the pipe update critical section
> >   drm/i915: Change intel_pipe_update_{start,end}() calling convention
> >   drm/i915: Extract intel_crtc_vblank_evade_scanlines()
> >   drm/i915: Enable VRR later during fastsets
> >   drm/i915: Adjust seamless_m_n flag behaviour
> >   drm/i915: Optimize out redundant M/N updates
> >   drm/i915: Relocate is_in_vrr_range()
> >   drm/i915: Validate that the timings are within the VRR range
> >   drm/i915: Disable VRR during seamless M/N changes
> >   drm/i915: Update VRR parameters in fastset
> >   drm/i915: Assert that VRR is off during vblank evasion if necessary
> >   drm/i915: Implement transcoder LRR for TGL+
> >
> >  drivers/gpu/drm/i915/display/intel_atomic.c   |   2 +
> >  drivers/gpu/drm/i915/display/intel_crtc.c | 110 --
> >  drivers/gpu/drm/i915/display/intel_crtc.h |   6 +-
> >  drivers/gpu/drm/i915/display/intel_display.c  | 135 ++
> >  .../drm/i915/display/intel_display_device.h   |   1 +
> >  .../drm/i915/display/intel_display_types.h|   5 +-
> >  drivers/gpu/drm/i915/display/intel_dp.c   |   2 +-
> >  drivers/gpu/drm/i915/display/intel_panel.c|  17 +--
> >  drivers/gpu/drm/i915/display/intel_vrr.c  |  18 ++-
> >  drivers/gpu/drm/i915/display/intel_vrr.h  |   1 +
> >  drivers/gpu/drm/i915/i915_reg.h   |   1 +
> >  11 files changed, 212 insertions(+), 86 deletions(-)
> >
> > --
> > 2.41.0
> >

-- 
Ville Syrjälä
Intel


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update GGTT with MI_UPDATE_GTT on MTL (rev8)

2023-09-20 Thread Patchwork
== Series Details ==

Series: Update GGTT with MI_UPDATE_GTT on MTL (rev8)
URL   : https://patchwork.freedesktop.org/series/123329/
State : warning

== Summary ==

Error: dim checkpatch failed
a1b7a590c8ed drm/i915: Lift runtime-pm acquire callbacks out of 
intel_wakeref.mutex
-:57: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#57: FILE: drivers/gpu/drm/i915/intel_wakeref.c:27:
+   INTEL_WAKEREF_BUG_ON(wf->wakeref);

-:73: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#73: FILE: drivers/gpu/drm/i915/intel_wakeref.c:40:
+   INTEL_WAKEREF_BUG_ON(atomic_read(&wf->count) <= 0);

-:96: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#96: FILE: drivers/gpu/drm/i915/intel_wakeref.c:60:
+   INTEL_WAKEREF_BUG_ON(!wf->wakeref);

total: 0 errors, 3 warnings, 0 checks, 83 lines checked
3d01a2c11682 drm/i915: Create a kernel context for GGTT updates
2ffbc0e31c81 drm/i915: Implement for_each_sgt_daddr_next
-:40: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__iter' - possible 
side-effects?
#40: FILE: drivers/gpu/drm/i915/i915_scatterlist.h:100:
+#define __for_each_daddr_next(__dp, __iter, __step)  \
+   for (; ((__dp) = (__iter).dma + (__iter).curr), (__iter).sgp;   \
+(((__iter).curr += (__step)) >= (__iter).max) ?\
+(__iter) = __sgt_iter(__sg_next((__iter).sgp), true), 0 : 0)

total: 0 errors, 0 warnings, 1 checks, 25 lines checked
dd718fef0407 drm/i915: Parameterize binder context creation
973aa7bf165a drm/i915: Implement GGTT update method with MI_UPDATE_GTT
-:69: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely 
unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of 
BUG() or variants
#69: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:276:
+   GEM_BUG_ON(!ce);

-:239: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#239: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:491:
+   if (!gen8_ggtt_bind_ptes(ggtt, start, vma_res->bi.pages,
+ vma_res->node_size / I915_GTT_PAGE_SIZE, pte_encode))

-:287: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#287: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:553:
+   if (should_update_ggtt_with_bind(ggtt) && gen8_ggtt_bind_ptes(ggtt, 
first_entry,
+NULL, num_entries, scratch_pte))

total: 0 errors, 1 warnings, 2 checks, 283 lines checked
d07b23f100b8 drm/i915: Toggle binder context ready status
19ca0a02d7ee drm/i915: Enable GGTT updates with binder in MTL




[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update GGTT with MI_UPDATE_GTT on MTL (rev8)

2023-09-20 Thread Patchwork
== Series Details ==

Series: Update GGTT with MI_UPDATE_GTT on MTL (rev8)
URL   : https://patchwork.freedesktop.org/series/123329/
State : warning

== Summary ==

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




Re: [Intel-gfx] [PATCH v2 12/12] drm/i915: Implement transcoder LRR for TGL+

2023-09-20 Thread Manasi Navare
On Wed, Sep 20, 2023 at 12:40 PM Ville Syrjälä
 wrote:
>
> On Wed, Sep 20, 2023 at 11:47:05AM -0700, Manasi Navare wrote:
> > Hi Ville,
> >
> > Quick question here on the use case and the trigger for the LRR case
> > which is within VRR range.
> > Could this perhaps be used if we had a virtual mode say 40Hz that now
> > falls in the VRR range (30 -120Hz) that is
> > exposed through the connector mode list and then if we do a modest to
> > 40Hz that would make update_lrr = true within VRR and
> > hand adjust the vtotal to that exact value?
> > I am looking at adding this virtual mode to DRM soon, wondering if
> > this would be how the kernel would actual set the timings for it.
>
> Userspace can supply any mode it wants. So just take whatever higher
> refresh rate mode you have and increase vtotal until you reach
> the desired lower vrefresh rate and feed that to the kernel.

Okay perfect that makes sense.
So effectively if i create specific modes lower than the highest
refresh rate, then
userspace can request a modeset to any of the lower refresh rate virtual mode
and the kernel would stretch out the vtotal manually corresponding to
the vtotal of
that virtual mode timing and modeset to that seamlessly in a fastset fashion.

Is this correct?

Regards
Manasi

>
> >
> > Regards
> > Manasi
> >
> > On Mon, Sep 18, 2023 at 4:16 PM Manasi Navare  
> > wrote:
> > >
> > > Thanks Ville for the respin, the changes look good now.
> > >
> > > Reviewed-by: Manasi Navare 
> > >
> > > Manasi
> > >
> > >
> > > On Fri, Sep 15, 2023 at 3:38 AM Ville Syrjala
> > >  wrote:
> > > >
> > > > From: Ville Syrjälä 
> > > >
> > > > Implement low refresh rate (LRR) where we change the vblank
> > > > length by hand as requested, but otherwise keep the timing
> > > > generator running in non-VRR mode (ie. fixed refresh rate).
> > > >
> > > > The panel itself must support VRR for this to work, and
> > > > only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that
> > > > we need to make the switch properly. The double buffer
> > > > latching happens at the start of transcoders undelayed
> > > > vblank. The other thing that we change is
> > > > TRANS_VBLANK.VBLANK_END but the hardware entirely ignores
> > > > that in DP mode. But I decided to keep writing it anyway
> > > > just to avoid more special cases in readout/state check.
> > > >
> > > > v2: Document that TRANS_VBLANK.VBLANK_END is ignored by
> > > > the hardware
> > > > v3: Reconcile with VRR fastset
> > > > Adjust update_lrr flag behaviour
> > > > Make sure timings stay within VRR range
> > > > v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi)
> > > > Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi)
> > > >
> > > > TODO: Hook LRR into the automatic DRRS downclocking stuff?
> > > >
> > > > Cc: Manasi Navare 
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_atomic.c   |  1 +
> > > >  drivers/gpu/drm/i915/display/intel_crtc.c |  9 +--
> > > >  drivers/gpu/drm/i915/display/intel_display.c  | 60 +--
> > > >  .../drm/i915/display/intel_display_device.h   |  1 +
> > > >  .../drm/i915/display/intel_display_types.h|  3 +-
> > > >  drivers/gpu/drm/i915/display/intel_vrr.c  |  7 ++-
> > > >  6 files changed, 70 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> > > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > index aaddd8c0cfa0..5d18145da279 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > > @@ -260,6 +260,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > > >
> > > > crtc_state->update_pipe = false;
> > > > crtc_state->update_m_n = false;
> > > > +   crtc_state->update_lrr = false;
> > > > crtc_state->disable_lp_wm = false;
> > > > crtc_state->disable_cxsr = false;
> > > > crtc_state->update_wm_pre = false;
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > index a39e31c1ca85..22e85fe7e8aa 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > > @@ -495,7 +495,7 @@ static void 
> > > > intel_crtc_vblank_evade_scanlines(struct intel_atomic_state *state,
> > > > if (crtc->mode_flags & I915_MODE_FLAG_VRR) {
> > > > /* timing changes should happen with VRR disabled */
> > > > drm_WARN_ON(state->base.dev, 
> > > > intel_crtc_needs_modeset(new_crtc_state) ||
> > > > -   new_crtc_state->update_m_n);
> > > > +   new_crtc_state->update_m_n || 
> > > > new_crtc_state->update_lrr);
> > > >
> > > > if (intel_vrr_is_push_sent(crtc_state))
> > > > *vblank_start = 
> > > > intel_vrr_vmin_vblank_start(crtc_state);
> > > > @@ -511,10 +511

Re: [Intel-gfx] [PATCH i-g-t] tests/i915_pm_freq_api: Set min/max to expected values

2023-09-20 Thread Rodrigo Vivi
On Wed, Sep 20, 2023 at 09:18:07AM -0700, Belgaumkar, Vinay wrote:
> 
> On 9/20/2023 7:07 AM, Rodrigo Vivi wrote:
> > On Mon, Sep 18, 2023 at 12:02:59PM -0700, Vinay Belgaumkar wrote:
> > > A prior(rps) test leaves the system in a bad state causing failures
> > > in the basic test.
> > Why?
> > 
> > What was the freq immediately before the failure that made the
> > machine to be busted and not accept the new freq request?
> > 
> > Maybe we should use this information to limit the freq requests
> > that we accept instead of workaround the test case. Otherwise
> > we are at risk of users selecting the bad freq that let " the
> > system in a bad state"...
> 
> i915_pm_rps (waitboost) test sets soft max_freq to some value less than RP0
> and then fails. The restore on failure does not work properly as the test is
> not multitile capable(it sets the root sysfs entry instead of using the per
> tile entry). Then, the current test (i915_pm_freq_api --r basic-api) tries
> to set min_freq to RP0 as part of normal testing. This fails as soft_max is
> < RP0.
> 
> There is some non-trivial effort needed to convert i915_pm_rps to multitile,
> and this is a BAT failure, hence adding the quick fix to ensure the test
> runs with a good pre-environment.

okay, right, regardless the issue on the other test, this one is working
with some assumptions that needs to be corrected.
We either correct the assumption and set the max while setting the min,
or we do like this patch and make the assumption true.

Let's go with your patch

Acked-by: Rodrigo Vivi 


> 
> Thanks,
> 
> Vinay.
> 
> > 
> > > Set min/max to expected values before running it.
> > > Test will restore values at the end.
> > > 
> > > Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8670
> > > 
> > > Signed-off-by: Vinay Belgaumkar 
> > > ---
> > >   tests/intel/i915_pm_freq_api.c | 8 ++--
> > >   1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tests/intel/i915_pm_freq_api.c 
> > > b/tests/intel/i915_pm_freq_api.c
> > > index 03bd0d05b..6018692a2 100644
> > > --- a/tests/intel/i915_pm_freq_api.c
> > > +++ b/tests/intel/i915_pm_freq_api.c
> > > @@ -55,7 +55,11 @@ static void test_freq_basic_api(int dirfd, int gt)
> > >   rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
> > >   rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
> > >   rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
> > > - igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d", gt, rpn, rpe, rp0);
> > > + igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d\n", gt, rpn, rpe, rp0);
> > > +
> > > + /* Set min/max to RPn, RP0 for baseline behavior */
> > > + igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
> > > + igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0) > 0);
> > >   /*
> > >* Negative bound tests
> > > @@ -170,7 +174,7 @@ igt_main
> > >   for_each_sysfs_gt_dirfd(i915, dirfd, gt) {
> > >   stash_min[gt] = get_freq(dirfd, 
> > > RPS_MIN_FREQ_MHZ);
> > >   stash_max[gt] = get_freq(dirfd, 
> > > RPS_MAX_FREQ_MHZ);
> > > - igt_debug("GT: %d, min: %d, max: %d", gt, 
> > > stash_min[gt], stash_max[gt]);
> > > + igt_debug("GT: %d, min: %d, max: %d\n", gt, 
> > > stash_min[gt], stash_max[gt]);
> > >   igt_pm_ignore_slpc_efficient_freq(i915, dirfd, 
> > > true);
> > >   }
> > >   igt_install_exit_handler(restore_sysfs_freq);
> > > -- 
> > > 2.38.1
> > > 


Re: [Intel-gfx] [PATCH v2] drm/i915/irq: Clear GFX_MSTR_IRQ as part of IRQ reset

2023-09-20 Thread Ville Syrjälä
On Wed, Sep 20, 2023 at 05:13:36PM -0300, Gustavo Sousa wrote:
> Quoting Ville Syrjälä (2023-09-20 17:00:07-03:00)
> >On Wed, Sep 20, 2023 at 04:53:52PM -0300, Gustavo Sousa wrote:
> >> Starting with Xe_LP+, GFX_MSTR_IRQ contains status bits that have W1C
> >> behavior. If we do not properly reset them, we would miss delivery of
> >> interrupts if a pending bit is set when enabling IRQs.
> >> 
> >> As an example, the display part of our probe routine contains paths
> >> where we wait for vblank interrupts. If a display interrupt was already
> >> pending when enabling IRQs, we would time out waiting for the vblank.
> >> 
> >> Avoid the potential issue by clearing GFX_MSTR_IRQ as part of the IRQ
> >> reset.
> >> 
> >> v2:
> >>   - Move logic from gen11_gt_irq_reset() to dg1_irq_reset(). (Matt)
> >> 
> >> BSpec: 50875, 54028
> >> Cc: Matt Roper 
> >> Signed-off-by: Gustavo Sousa 
> >> ---
> >>  drivers/gpu/drm/i915/i915_irq.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 1bfcfbe6e30b..8130f043693b 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -751,6 +751,8 @@ static void dg1_irq_reset(struct drm_i915_private 
> >> *dev_priv)
> >>  
> >>  GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> >>  GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> >> +
> >> +intel_uncore_write(uncore, GEN11_GFX_MSTR_IRQ, ~0);
> >
> >Did you confirm that it's not double buffered?
> 
> Ah, sorry... I forgot to mention on the original thread where you asked:
> 
>   - BSpec 50875 and 66434 (for Xe2) does not say that GFX_MSTR_IRQ is
> double buffered. In fact they mention the fact that display IIR
> registers are double buffered and require multiple writes to fully
> clear, but does not say the same about GFX_MSTR_IRQ.
> 
>   - Also, BSpec 54028 does not mention that the register is double
> buffered.
> 
> Based on the above, I'm assuming it is not double buffered.
> 
> Should I check other sources? Is there some sort of runtime check that
> can be done?

I'd probably just poke at it with intel_reg. Eg:
1. boot w/o driver
2. unmask+enable eg. pipe vblank interrupt in GEN8_DE_PIPE_IMR/IER
3. make sure GEN11_DISPLAY_INT_CTL sees it
4. enable GEN11_DISPLAY_IRQ_ENABLE
5. make sure GEN11_GFX_MSTR_IRQ see it
6. toggle GEN11_DISPLAY_IRQ_ENABLE a few more times to generate extra edges
7. try to clear the bit in GEN11_GFX_MSTR_IRQ
8. did the bit clear?
   yes -> single buffered
   no -> goto 7 and check again to make sure it clears on the second time 
around -> double buffered

> 
> --
> Gustavo Sousa
> 
> >
> >>  }
> >>  
> >>  static void cherryview_irq_reset(struct drm_i915_private *dev_priv)
> >> -- 
> >> 2.42.0
> >
> >-- 
> >Ville Syrjälä
> >Intel

-- 
Ville Syrjälä
Intel


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Remove gtt_offset from stream->oa_buffer.head/.tail (rev2)

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: Remove gtt_offset from stream->oa_buffer.head/.tail 
(rev2)
URL   : https://patchwork.freedesktop.org/series/123949/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13658 -> Patchwork_123949v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (32 -> 39)
--

  Additional (9): bat-mtlp-8 bat-dg2-9 fi-ilk-650 fi-hsw-4770 fi-glk-j4005 
fi-cfl-8109u fi-pnv-d510 fi-bsw-nick fi-skl-6600u 
  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#9318])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_exec_suspend@basic-s0@lmem0:
- bat-dg2-9:  NOTRUN -> [INCOMPLETE][2] ([i915#9275])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- fi-bsw-nick:NOTRUN -> [SKIP][6] ([fdo#109271]) +18 other tests 
skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/fi-bsw-nick/igt@gem_lmem_swapp...@parallel-random-engines.html
- bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#4613]) +3 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-glk-j4005:   NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/fi-glk-j4005/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- fi-skl-6600u:   NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/fi-skl-6600u/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- fi-cfl-8109u:   NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) +3 
other tests skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_mmap@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#4083])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-mtlp-8/igt@gem_m...@basic.html
- bat-dg2-9:  NOTRUN -> [SKIP][12] ([i915#4083])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-dg2-9/igt@gem_m...@basic.html

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][13] ([i915#4077]) +2 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-dg2-9/igt@gem_mmap_...@basic.html

  * igt@gem_render_tiled_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#4079]) +1 other test skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-mtlp-8/igt@gem_render_tiled_bl...@basic.html

  * igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][15] ([fdo#109271]) +13 other tests 
skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html

  * igt@gem_tiled_fence_blits@basic:
- bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#4077]) +3 other tests skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-mtlp-8/igt@gem_tiled_fence_bl...@basic.html

  * igt@gem_tiled_pread_basic:
- bat-dg2-9:  NOTRUN -> [SKIP][17] ([i915#4079]) +1 other test skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/bat-dg2-9/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-ilk-650: NOTRUN -> [SKIP][18] ([fdo#109271]) +21 other tests 
skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123949v2/fi-ilk-650/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_pm_rps@basic-api:
- bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#6621])
   [19]: 
https://intel

Re: [Intel-gfx] [PATCH v2] drm/i915/irq: Clear GFX_MSTR_IRQ as part of IRQ reset

2023-09-20 Thread Gustavo Sousa
Quoting Ville Syrjälä (2023-09-20 17:00:07-03:00)
>On Wed, Sep 20, 2023 at 04:53:52PM -0300, Gustavo Sousa wrote:
>> Starting with Xe_LP+, GFX_MSTR_IRQ contains status bits that have W1C
>> behavior. If we do not properly reset them, we would miss delivery of
>> interrupts if a pending bit is set when enabling IRQs.
>> 
>> As an example, the display part of our probe routine contains paths
>> where we wait for vblank interrupts. If a display interrupt was already
>> pending when enabling IRQs, we would time out waiting for the vblank.
>> 
>> Avoid the potential issue by clearing GFX_MSTR_IRQ as part of the IRQ
>> reset.
>> 
>> v2:
>>   - Move logic from gen11_gt_irq_reset() to dg1_irq_reset(). (Matt)
>> 
>> BSpec: 50875, 54028
>> Cc: Matt Roper 
>> Signed-off-by: Gustavo Sousa 
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 1bfcfbe6e30b..8130f043693b 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -751,6 +751,8 @@ static void dg1_irq_reset(struct drm_i915_private 
>> *dev_priv)
>>  
>>  GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
>>  GEN3_IRQ_RESET(uncore, GEN8_PCU_);
>> +
>> +intel_uncore_write(uncore, GEN11_GFX_MSTR_IRQ, ~0);
>
>Did you confirm that it's not double buffered?

Ah, sorry... I forgot to mention on the original thread where you asked:

  - BSpec 50875 and 66434 (for Xe2) does not say that GFX_MSTR_IRQ is
double buffered. In fact they mention the fact that display IIR
registers are double buffered and require multiple writes to fully
clear, but does not say the same about GFX_MSTR_IRQ.

  - Also, BSpec 54028 does not mention that the register is double
buffered.

Based on the above, I'm assuming it is not double buffered.

Should I check other sources? Is there some sort of runtime check that
can be done?

--
Gustavo Sousa

>
>>  }
>>  
>>  static void cherryview_irq_reset(struct drm_i915_private *dev_priv)
>> -- 
>> 2.42.0
>
>-- 
>Ville Syrjälä
>Intel


Re: [Intel-gfx] [PATCH v2] drm/i915/irq: Clear GFX_MSTR_IRQ as part of IRQ reset

2023-09-20 Thread Ville Syrjälä
On Wed, Sep 20, 2023 at 04:53:52PM -0300, Gustavo Sousa wrote:
> Starting with Xe_LP+, GFX_MSTR_IRQ contains status bits that have W1C
> behavior. If we do not properly reset them, we would miss delivery of
> interrupts if a pending bit is set when enabling IRQs.
> 
> As an example, the display part of our probe routine contains paths
> where we wait for vblank interrupts. If a display interrupt was already
> pending when enabling IRQs, we would time out waiting for the vblank.
> 
> Avoid the potential issue by clearing GFX_MSTR_IRQ as part of the IRQ
> reset.
> 
> v2:
>   - Move logic from gen11_gt_irq_reset() to dg1_irq_reset(). (Matt)
> 
> BSpec: 50875, 54028
> Cc: Matt Roper 
> Signed-off-by: Gustavo Sousa 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1bfcfbe6e30b..8130f043693b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -751,6 +751,8 @@ static void dg1_irq_reset(struct drm_i915_private 
> *dev_priv)
>  
>   GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
>   GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> +
> + intel_uncore_write(uncore, GEN11_GFX_MSTR_IRQ, ~0);

Did you confirm that it's not double buffered?

>  }
>  
>  static void cherryview_irq_reset(struct drm_i915_private *dev_priv)
> -- 
> 2.42.0

-- 
Ville Syrjälä
Intel


[Intel-gfx] [PATCH 2/4] drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo Yoga Tablet 2 series (v3)

2023-09-20 Thread Hans de Goede
On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:

1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
   which under Linux become bus 0 - 6. And the MIPI sequence reference
   to bus 3 is indented for I2C3 which is bus 2 under Linux.

   This leads to errors like these:
   [  178.244049] i2c_designware 80860F41:03: controller timed out
   [  178.245703] i915 :00:02.0: [drm] *ERROR* Failed to xfer payload of 
size (1) to reg (169)
   There are 3 timeouts when the panel is on, delaying
   waking up the screen on a key press by 3 seconds.

   Note mipi_exec_i2c() cannot just subtract 1 from the bus
   given in the I2C MIPI sequence element. Since on other
   devices the I2C bus-numbers used in the MIPI sequences do
   actually start at 0.

2. width_/height_mm contain a bogus 192mm x 120mm size. This is
   especially a problem on the 8" 830 version which uses a 10:16
   portrait screen where as the bogus size is 16:10.

Add a DMI quirk to override the I2C bus and the panel size with
the correct values.

Note both the 10" 1050 models as well as the 8" 830 models use the same
mainboard and thus the same DMI strings. The 10" 1050 uses a 1920x1200
landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen,
so the quirk handling uses the display resolution to detect the model.

v2:
- Also override i2c_bus_num to fix mipi_exec_i2c() timeouts

v3:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9379
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 0d3aabf6a1dd..f69cafe8a17d 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1767,6 +1767,44 @@ static void vlv_dsi_asus_tf103c_mode_fixup(struct 
intel_dsi *intel_dsi)
fixed_mode->vtotal -= 4;
 }
 
+/*
+ * On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems:
+ * 1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7
+ *which under Linux become bus 0 - 6. And the MIPI sequence reference
+ *to bus 3 is indented for I2C3 which is bus 2 under Linux.
+ *
+ *Note mipi_exec_i2c() cannot just subtract 1 from the bus
+ *given in the I2C MIPI sequence element. Since on other
+ *devices the I2C bus-numbers used in the MIPI sequences do
+ *actually start at 0.
+ *
+ * 2. width_/height_mm contain a bogus 192mm x 120mm size. This is
+ *especially a problem on the 8" 830 version which uses a 10:16
+ *portrait screen where as the bogus size is 16:10.
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9379
+ */
+static void vlv_dsi_lenovo_yoga_tab2_size_fixup(struct intel_dsi *intel_dsi)
+{
+   const struct drm_display_mode *fixed_mode =
+   intel_panel_preferred_fixed_mode(intel_dsi->attached_connector);
+   struct drm_display_info *info = 
&intel_dsi->attached_connector->base.display_info;
+
+   intel_dsi->i2c_bus_num = 2;
+
+   /*
+* The 10" 1050 uses a 1920x1200 landscape screen, where as the 8" 830
+* uses a 1200x1920 portrait screen.
+*/
+   if (fixed_mode->hdisplay == 1920) {
+   info->width_mm = 216;
+   info->height_mm = 135;
+   } else {
+   info->width_mm = 107;
+   info->height_mm = 171;
+   }
+}
+
 static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
{
/* Asus Transformer Pad TF103C */
@@ -1776,6 +1814,20 @@ static const struct dmi_system_id 
vlv_dsi_dmi_quirk_table[] = {
},
.driver_data = (void *)vlv_dsi_asus_tf103c_mode_fixup,
},
+   {
+   /*
+* Lenovo Yoga Tablet 2 830F/L or 1050F/L (The 8" and 10"
+* Lenovo Yoga Tablet 2 use the same mainboard)
+*/
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Intel Corp."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "VALLEYVIEW C0 PLATFORM"),
+   DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
+   /* Partial match on beginning of BIOS version */
+   DMI_MATCH(DMI_BIOS_VERSION, "BLADE_21"),
+   },
+   .driver_data = (void *)vlv_dsi_lenovo_yoga_tab2_size_fixup,
+   },
{ }
 };
 
-- 
2.41.0



[Intel-gfx] [PATCH 3/4] drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga Tab 3 (v2)

2023-09-20 Thread Hans de Goede
On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 issues with the backlight
on/off MIPI sequences:

1. The backlight on sequence has an I2C MIPI sequence element which uses
   bus 0, but there is a bogus I2cSerialBus resource under the GPU in
   the DSDT which causes i2c_acpi_find_adapter() to pick the wrong bus.

2. There is no backlight off sequence, causing the backlight to stay on.

Add a DMI quirk fixing both issues.

v2:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9380
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index f69cafe8a17d..55da627a8b8d 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -1805,6 +1805,31 @@ static void vlv_dsi_lenovo_yoga_tab2_size_fixup(struct 
intel_dsi *intel_dsi)
}
 }
 
+/*
+ * On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 problems:
+ * 1. i2c_acpi_find_adapter() picks the wrong adapter causing mipi_exec_i2c()
+ *to not work. Fix this by setting i2c_bus_num.
+ * 2. There is no backlight off MIPI sequence, causing the backlight to stay 
on.
+ *Add a backlight off sequence mirroring the existing backlight on 
sequence.
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9380
+ */
+static void vlv_dsi_lenovo_yoga_tab3_backlight_fixup(struct intel_dsi 
*intel_dsi)
+{
+   static const u8 backlight_off_sequence[16] = {
+   /* Header Seq-id 7, length after header 11 bytes */
+   0x07, 0x0b, 0x00, 0x00, 0x00,
+   /* MIPI_SEQ_ELEM_I2C bus 0 addr 0x2c reg 0x00 data-len 1 data 
0x00 */
+   0x04, 0x08, 0x00, 0x00, 0x00, 0x2c, 0x00, 0x00, 0x01, 0x00,
+   /* MIPI_SEQ_ELEM_END */
+   0x00
+   };
+   struct intel_connector *connector = intel_dsi->attached_connector;
+
+   intel_dsi->i2c_bus_num = 0;
+   connector->panel.vbt.dsi.sequence[MIPI_SEQ_BACKLIGHT_OFF] = 
backlight_off_sequence;
+}
+
 static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
{
/* Asus Transformer Pad TF103C */
@@ -1828,6 +1853,15 @@ static const struct dmi_system_id 
vlv_dsi_dmi_quirk_table[] = {
},
.driver_data = (void *)vlv_dsi_lenovo_yoga_tab2_size_fixup,
},
+   {
+   /* Lenovo Yoga Tab 3 Pro YT3-X90F */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+   DMI_MATCH(DMI_PRODUCT_VERSION, "Blade3-10A-001"),
+   },
+   .driver_data = (void *)vlv_dsi_lenovo_yoga_tab3_backlight_fixup,
+   },
{ }
 };
 
-- 
2.41.0



[Intel-gfx] [PATCH 4/4] drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)

2023-09-20 Thread Hans de Goede
Add some debug logging to mipi_exec_i2c, to make debugging various
issues seen with it easier.

Changes in v2:
- Drop unnecessary __func__ drm_dbg_kms() argument

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index e56ec3f2d84a..24b2cbcfc1ef 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -565,6 +565,9 @@ static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, 
const u8 *data)
u8 payload_size = *(data + 6);
u8 *payload_data;
 
+   drm_dbg_kms(&i915->drm, "bus %d client-addr 0x%02x reg 0x%02x data 
%*ph\n",
+   vbt_i2c_bus_num, slave_addr, reg_offset, payload_size, data 
+ 7);
+
if (intel_dsi->i2c_bus_num < 0) {
intel_dsi->i2c_bus_num = vbt_i2c_bus_num;
i2c_acpi_find_adapter(intel_dsi, slave_addr);
-- 
2.41.0



[Intel-gfx] [PATCH 1/4] drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus TF103C (v3)

2023-09-20 Thread Hans de Goede
Vtotal is wrong in the BIOS supplied modeline for the DSI panel on
the Asus TF103C leading to the last line of the display being shown
as the first line.

Original: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 0xa
Fixed:"1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 0xa

The factory installed Android has a hardcoded modeline in its kernel,
causing it to not suffer from this BIOS bug;
and the Android boot-splash which uses the EFI FB which does have this bug
has the last line all black causing the bug to not be visible.

This commit introduces a generic DMI based quirk mechanism to vlv_dsi for
doing various fixups, and uses this to correct the modeline.

v2:
- s/mode_fixup/dmi_quirk/ to make the new DMI quirk mechanism more generic
- Add a comment with the old and new modelines to the patch and commit msg

v3:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9381
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/display/vlv_dsi.c | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index a96e7d028c5c..0d3aabf6a1dd 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -23,6 +23,7 @@
  * Author: Jani Nikula 
  */
 
+#include 
 #include 
 
 #include 
@@ -1744,6 +1745,40 @@ static void vlv_dphy_param_init(struct intel_dsi 
*intel_dsi)
intel_dsi_log_params(intel_dsi);
 }
 
+typedef void (*vlv_dsi_dmi_quirk_func)(struct intel_dsi *intel_dsi);
+
+/*
+ * Vtotal is wrong on the Asus TF103C leading to the last line of the display
+ * being shown as the first line. The factory installed Android has a hardcoded
+ * modeline, causing it to not suffer from this BIOS bug.
+ *
+ * Original mode: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 
0xa
+ * Fixedmode: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 
0xa
+ *
+ * https://gitlab.freedesktop.org/drm/intel/-/issues/9381
+ */
+static void vlv_dsi_asus_tf103c_mode_fixup(struct intel_dsi *intel_dsi)
+{
+   /* Cast away the const as we want to fixup the mode */
+   struct drm_display_mode *fixed_mode = (struct drm_display_mode *)
+   intel_panel_preferred_fixed_mode(intel_dsi->attached_connector);
+
+   if (fixed_mode->vtotal == 820)
+   fixed_mode->vtotal -= 4;
+}
+
+static const struct dmi_system_id vlv_dsi_dmi_quirk_table[] = {
+   {
+   /* Asus Transformer Pad TF103C */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "TF103C"),
+   },
+   .driver_data = (void *)vlv_dsi_asus_tf103c_mode_fixup,
+   },
+   { }
+};
+
 void vlv_dsi_init(struct drm_i915_private *dev_priv)
 {
struct intel_dsi *intel_dsi;
@@ -1752,6 +1787,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
struct intel_connector *intel_connector;
struct drm_connector *connector;
struct drm_display_mode *current_mode;
+   const struct dmi_system_id *dmi_id;
enum port port;
enum pipe pipe;
 
@@ -1883,6 +1919,14 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
goto err_cleanup_connector;
}
 
+   dmi_id = dmi_first_match(vlv_dsi_dmi_quirk_table);
+   if (dmi_id) {
+   vlv_dsi_dmi_quirk_func quirk_func =
+   (vlv_dsi_dmi_quirk_func)dmi_id->driver_data;
+
+   quirk_func(intel_dsi);
+   }
+
intel_panel_init(intel_connector, NULL);
 
intel_backlight_setup(intel_connector, INVALID_PIPE);
-- 
2.41.0



[Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v3)

2023-09-20 Thread Hans de Goede
Hi All,

Some vlv/chv tablets ship with Android as factory OS. The factory OS
BSP style kernel on these tablets does not use the normal x86 hw
autodetection instead it hardcodes a whole bunch of things including
using panel drivers instead of relying on VBT MIPI sequences to
turn the panel/backlight on/off.

The normal i915 driver (which does not use panel drivers) mostly works
since the VBT still needs to contain valid info for the GOP, but because
of the Android kernel relying on panel drivers with various things
hardcoded some DMI quirks are necessary to fix some issues on these
devices.

Some of these issues also are related to which I2C bus to use for
MIPI sequence elements which do I2C transfers. This series also
includes a patch adding some extra debugging to mipi_exec_i2c() to
help with debugging similar issues in the future.

These patches have been posted before but back then I did not get around
to follow up on the series:
https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/

v2:
- Drop the changes how the I2C bus number is found, instead just have
  the quirks set the right number directly where necessary. This should
  avoid any chances of causing regressions on devices where the quirks
  do not apply.
- New quirk for backlight control issues on Lenovo Yoga Tab 3
- Address Jani Nikula's remark about __func__ being redundant when using
  drm_dbg_kms()

v3:
- File 3 gitlab issues with drm.debug=0xe dmesg output, VBT dump for all
  3 affected models. Add Closes: tags with links to gitlab issues

Regards,

Hans


Hans de Goede (4):
  drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on
Asus TF103C (v3)
  drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on
Lenovo Yoga Tablet 2 series (v3)
  drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo
Yoga Tab 3 (v2)
  drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)

 drivers/gpu/drm/i915/display/intel_dsi_vbt.c |   3 +
 drivers/gpu/drm/i915/display/vlv_dsi.c   | 124 +++
 2 files changed, 127 insertions(+)

-- 
2.41.0



[Intel-gfx] [PATCH v2] drm/i915/irq: Clear GFX_MSTR_IRQ as part of IRQ reset

2023-09-20 Thread Gustavo Sousa
Starting with Xe_LP+, GFX_MSTR_IRQ contains status bits that have W1C
behavior. If we do not properly reset them, we would miss delivery of
interrupts if a pending bit is set when enabling IRQs.

As an example, the display part of our probe routine contains paths
where we wait for vblank interrupts. If a display interrupt was already
pending when enabling IRQs, we would time out waiting for the vblank.

Avoid the potential issue by clearing GFX_MSTR_IRQ as part of the IRQ
reset.

v2:
  - Move logic from gen11_gt_irq_reset() to dg1_irq_reset(). (Matt)

BSpec: 50875, 54028
Cc: Matt Roper 
Signed-off-by: Gustavo Sousa 
---
 drivers/gpu/drm/i915/i915_irq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1bfcfbe6e30b..8130f043693b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -751,6 +751,8 @@ static void dg1_irq_reset(struct drm_i915_private *dev_priv)
 
GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+
+   intel_uncore_write(uncore, GEN11_GFX_MSTR_IRQ, ~0);
 }
 
 static void cherryview_irq_reset(struct drm_i915_private *dev_priv)
-- 
2.42.0



Re: [Intel-gfx] [PATCH 0/4] drm/i915/vlv_dsi: Add quirks for x86 android tablets (v2)

2023-09-20 Thread Hans de Goede
Hi Ville,

On 9/18/23 10:00, Ville Syrjälä wrote:
> On Sat, Sep 16, 2023 at 02:54:51PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Some vlv/chv tablets ship with Android as factory OS. The factory OS
>> BSP style kernel on these tablets does not use the normal x86 hw
>> autodetection instead it hardcodes a whole bunch of things including
>> using panel drivers instead of relying on VBT MIPI sequences to
>> turn the panel/backlight on/off.
>>
>> The normal i915 driver (which does not use panel drivers) mostly works
>> since the VBT still needs to contain valid info for the GOP, but because
>> of the Android kernel relying on panel drivers with various things
>> hardcoded some DMI quirks are necessary to fix some issues on these
>> devices.
>>
>> Some of these issues also are related to which I2C bus to use for
>> MIPI sequence elements which do I2C transfers. This series also
>> includes a patch adding some extra debugging to mipi_exec_i2c() to
>> help with debugging similar issues in the future.
>>
>> These patches have been posted before but back then I did not get around
>> to follow up on the series:
>> https://lore.kernel.org/intel-gfx/20220225214934.383168-1-hdego...@redhat.com/
>>
>> Changes compared to this old version:
>> - Drop the changes how the I2C bus number is found, instead just have
>>   the quirks set the right number directly where necessary. This should
>>   avoid any chances of causing regressions on devices where the quirks
>>   do not apply.
>>
>> - New quirk for backlight control issues on Lenovo Yoga Tab 3
>>
>> - Address Jani Nikula's remark about __func__ being redundant when using
>>   drm_dbg_kms()
>>
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>> Hans de Goede (4):
>>   drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on
>> Asus TF103C (v2)
>>   drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on
>> Lenovo Yoga Tablet 2 series (v2)
>>   drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo
>> Yoga Tab 3
> 
> Please file a bug for each of these and attach the usual drm.debug=0xe
> dmesg + VBT + any other relevant information there. Otherwise a few
> years from now I'll be cursing at these commits as well for not leaving
> a decent papertrail...

Ok. I've just completed filing 3 issues (1 per affected model) and
I've added Closes: tags to the patches pointing to the issues.

I'll send out a v3 of this series with the Closes tags.

Regards,

Hans



> 
>>   drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)
>>
>>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c |   3 +
>>  drivers/gpu/drm/i915/display/vlv_dsi.c   | 124 +++
>>  2 files changed, 127 insertions(+)
>>
>> -- 
>> 2.41.0
> 



Re: [Intel-gfx] [PATCH v2 12/12] drm/i915: Implement transcoder LRR for TGL+

2023-09-20 Thread Ville Syrjälä
On Wed, Sep 20, 2023 at 11:47:05AM -0700, Manasi Navare wrote:
> Hi Ville,
> 
> Quick question here on the use case and the trigger for the LRR case
> which is within VRR range.
> Could this perhaps be used if we had a virtual mode say 40Hz that now
> falls in the VRR range (30 -120Hz) that is
> exposed through the connector mode list and then if we do a modest to
> 40Hz that would make update_lrr = true within VRR and
> hand adjust the vtotal to that exact value?
> I am looking at adding this virtual mode to DRM soon, wondering if
> this would be how the kernel would actual set the timings for it.

Userspace can supply any mode it wants. So just take whatever higher
refresh rate mode you have and increase vtotal until you reach
the desired lower vrefresh rate and feed that to the kernel.

> 
> Regards
> Manasi
> 
> On Mon, Sep 18, 2023 at 4:16 PM Manasi Navare  
> wrote:
> >
> > Thanks Ville for the respin, the changes look good now.
> >
> > Reviewed-by: Manasi Navare 
> >
> > Manasi
> >
> >
> > On Fri, Sep 15, 2023 at 3:38 AM Ville Syrjala
> >  wrote:
> > >
> > > From: Ville Syrjälä 
> > >
> > > Implement low refresh rate (LRR) where we change the vblank
> > > length by hand as requested, but otherwise keep the timing
> > > generator running in non-VRR mode (ie. fixed refresh rate).
> > >
> > > The panel itself must support VRR for this to work, and
> > > only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that
> > > we need to make the switch properly. The double buffer
> > > latching happens at the start of transcoders undelayed
> > > vblank. The other thing that we change is
> > > TRANS_VBLANK.VBLANK_END but the hardware entirely ignores
> > > that in DP mode. But I decided to keep writing it anyway
> > > just to avoid more special cases in readout/state check.
> > >
> > > v2: Document that TRANS_VBLANK.VBLANK_END is ignored by
> > > the hardware
> > > v3: Reconcile with VRR fastset
> > > Adjust update_lrr flag behaviour
> > > Make sure timings stay within VRR range
> > > v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi)
> > > Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi)
> > >
> > > TODO: Hook LRR into the automatic DRRS downclocking stuff?
> > >
> > > Cc: Manasi Navare 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_atomic.c   |  1 +
> > >  drivers/gpu/drm/i915/display/intel_crtc.c |  9 +--
> > >  drivers/gpu/drm/i915/display/intel_display.c  | 60 +--
> > >  .../drm/i915/display/intel_display_device.h   |  1 +
> > >  .../drm/i915/display/intel_display_types.h|  3 +-
> > >  drivers/gpu/drm/i915/display/intel_vrr.c  |  7 ++-
> > >  6 files changed, 70 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > index aaddd8c0cfa0..5d18145da279 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > @@ -260,6 +260,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > >
> > > crtc_state->update_pipe = false;
> > > crtc_state->update_m_n = false;
> > > +   crtc_state->update_lrr = false;
> > > crtc_state->disable_lp_wm = false;
> > > crtc_state->disable_cxsr = false;
> > > crtc_state->update_wm_pre = false;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index a39e31c1ca85..22e85fe7e8aa 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -495,7 +495,7 @@ static void intel_crtc_vblank_evade_scanlines(struct 
> > > intel_atomic_state *state,
> > > if (crtc->mode_flags & I915_MODE_FLAG_VRR) {
> > > /* timing changes should happen with VRR disabled */
> > > drm_WARN_ON(state->base.dev, 
> > > intel_crtc_needs_modeset(new_crtc_state) ||
> > > -   new_crtc_state->update_m_n);
> > > +   new_crtc_state->update_m_n || 
> > > new_crtc_state->update_lrr);
> > >
> > > if (intel_vrr_is_push_sent(crtc_state))
> > > *vblank_start = 
> > > intel_vrr_vmin_vblank_start(crtc_state);
> > > @@ -511,10 +511,11 @@ static void 
> > > intel_crtc_vblank_evade_scanlines(struct intel_atomic_state *state,
> > > *max = *vblank_start - 1;
> > >
> > > /*
> > > -* M/N is double buffered on the transcoder's undelayed vblank,
> > > -* so with seamless M/N we must evade both vblanks.
> > > +* M/N and TRANS_VTOTAL are double buffered on the transcoder's
> > > +* undelayed vblank, so with seamless M/N and LRR we must evade
> > > +* both vblanks.
> > >  */
> > > -   if (new_crtc_state->update_m_n)
> > > +   if (new_crtc_state->update_m_n || new_crtc_state->update_lrr)
> > >  

Re: [Intel-gfx] [PATCH] drm/edid: Fixup h/vsync_end instead of h/vtotal

2023-09-20 Thread Ville Syrjälä
On Wed, Sep 20, 2023 at 08:40:00PM +0300, Jani Nikula wrote:
> On Thu, 14 Sep 2023, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > There are some weird EDIDs floating around that have the sync
> > pulse extending beyond the end of the blanking period.
> >
> > On the currently problemtic machine (HP Omni 120) EDID reports
> > the following mode:
> > "1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
> > which is then "corrected" to have htotal=1861 by the current drm_edid.c
> > code.
> >
> > The fixup code was originally added in commit 7064fef56369 ("drm: work
> > around EDIDs with bad htotal/vtotal values"). Googling around we end up in
> > https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245
> > where we find an EDID for a Dell Studio 15, which reports:
> > (II) VESA(0): clock: 65.0 MHz   Image Size:  331 x 207 mm
> > (II) VESA(0): h_active: 1280  h_sync: 1328  h_sync_end 1360 h_blank_end 
> > 1337 h_border: 0
> > (II) VESA(0): v_active: 800  v_sync: 803  v_sync_end 809 v_blanking: 810 
> > v_border: 0
> >
> > Note that if we use the hblank size (as opposed of the hsync_end)
> > from the DTD to determine htotal we get exactly 60Hz refresh rate in
> > both cases, whereas using hsync_end to determine htotal we get a
> > slightly lower refresh rates. This makes me believe the using the
> > hblank size is what was intended even in those cases.
> >
> > Also note that in case of the HP Onmi 120 the VBIOS boots with these:
> >   crtc timings: 108000 1600 1780 1860 1800 900 910 913 1000, type: 0x40 
> > flags: 0x5
> > ie. it just blindly stuffs the bogus hsync_end and htotal from the DTD
> > into the transcoder timing registers, and the display works. I believe
> > the (at least more modern) hardware will automagically terminate the hsync
> > pulse when the timing generator reaches htotal, which again points that we
> > should use the hblank size to determine htotal. Unfortunatley the old bug
> > reports for the Dell machines are extremely lacking in useful details so
> > we have no idea what kind of timings the VBIOS programmed into the
> > hardware :(
> >
> > Let's just flip this quirk around and reduce the length of the sync
> > pulse instead of extending the blanking period. This at least seems
> > to be the correct thing to do on more modern hardware. And if any
> > issues crop up on older hardware we need to debug them properly.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8895
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 39dd3f694544..0c5563b4d21e 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3497,11 +3497,11 @@ static struct drm_display_mode 
> > *drm_mode_detailed(struct drm_connector *connecto
> > mode->vsync_end = mode->vsync_start + vsync_pulse_width;
> > mode->vtotal = mode->vdisplay + vblank;
> >  
> > -   /* Some EDIDs have bogus h/vtotal values */
> > +   /* Some EDIDs have bogus h/vsync_end values */
> > if (mode->hsync_end > mode->htotal)
> > -   mode->htotal = mode->hsync_end + 1;
> > +   mode->hsync_end = mode->htotal;
> > if (mode->vsync_end > mode->vtotal)
> > -   mode->vtotal = mode->vsync_end + 1;
> > +   mode->vsync_end = mode->vtotal;
> 
> I wonder if we shouldn't debug log these to help our future selves?

Yeah, might be a good idea. I can respin with that. I noticed
that our VBT parser has the exact same code in it as well so
I'll be wanting to cook up a patch that as well.

> 
> Anyway,
> 
> Reviewed-by: Jani Nikula 

Ta.

> 
> 
> >  
> > drm_mode_do_interlace_quirk(mode, pt);
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel


[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove unnecessary memory quiescing for aux inval

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove unnecessary memory quiescing for aux inval
URL   : https://patchwork.freedesktop.org/series/123975/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13655_full -> Patchwork_123975v1_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_123975v1_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_123975v1_full, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_123975v1_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-mtlp: [PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-mtlp-1/igt@kms_big...@x-tiled-64bpp-rotate-0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-mtlp-5/igt@kms_big...@x-tiled-64bpp-rotate-0.html

  * igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-glk4/igt@kms_flip@2x-flip-vs-dpms-off-vs-mode...@ab-hdmi-a1-hdmi-a2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-glk1/igt@kms_flip@2x-flip-vs-dpms-off-vs-mode...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_selftest@drm_plane:
- shard-dg2:  NOTRUN -> [TIMEOUT][5] +1 other test timeout
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-dg2-11/igt@kms_selftest@drm_plane.html

  * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-dg2:  [PASS][6] -> [INCOMPLETE][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-dg2-1/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-dg2-1/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html

  
 Warnings 

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [INCOMPLETE][8] ([i915#5566]) -> [INCOMPLETE][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-apl1/igt@gen9_exec_pa...@allowed-single.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-apl6/igt@gen9_exec_pa...@allowed-single.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@blit-reloc-purge-cache:
- shard-dg2:  NOTRUN -> [SKIP][10] ([i915#8411])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-dg2-11/igt@api_intel...@blit-reloc-purge-cache.html

  * igt@debugfs_test@basic-hwmon:
- shard-tglu: NOTRUN -> [SKIP][11] ([i915#9318])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-tglu-10/igt@debugfs_t...@basic-hwmon.html

  * igt@drm_fdinfo@busy-check-all@ccs0:
- shard-mtlp: NOTRUN -> [SKIP][12] ([i915#8414]) +5 other tests skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-mtlp-6/igt@drm_fdinfo@busy-check-...@ccs0.html

  * igt@drm_fdinfo@busy@ccs0:
- shard-dg2:  NOTRUN -> [SKIP][13] ([i915#8414]) +20 other tests 
skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-dg2-6/igt@drm_fdinfo@b...@ccs0.html

  * igt@gem_bad_reloc@negative-reloc:
- shard-mtlp: NOTRUN -> [SKIP][14] ([i915#3281])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-mtlp-6/igt@gem_bad_re...@negative-reloc.html

  * igt@gem_basic@multigpu-create-close:
- shard-dg2:  NOTRUN -> [SKIP][15] ([i915#7697])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-dg2-11/igt@gem_ba...@multigpu-create-close.html

  * igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-smem-lmem0:
- shard-dg2:  [PASS][16] -> [INCOMPLETE][17] ([i915#7297])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-dg2-6/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-dg2-6/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html

  * igt@gem_ctx_persistence@engines-persistence:
- shard-snb:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#1099]) +2 
other tests skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/shard-snb2/igt@gem_ctx_persiste...@engines-persistence.html

  * igt@gem_ctx_persistence@heartb

Re: [Intel-gfx] [PATCH 00/12] drm/i915: VRR, LRR, and M/N stuff

2023-09-20 Thread Manasi Navare
Hi Ville,

After the comments have been addressed, I have completed reviewing the
patches. Is there anything
else blocking this from getting merged? Could we get this merged if
everything looks good?

Regards
Manasi

On Fri, Sep 1, 2023 at 6:04 AM Ville Syrjala
 wrote:
>
> From: Ville Syrjälä 
>
> Attempt to make VRR, LRR, and M/N updates coexist nicely,
> allowing fastsets whenever feasible.
>
> Lightly smoke tested on my adl.
>
> Cc: Manasi Navare 
>
> Ville Syrjälä (12):
>   drm/i915: Move psr unlock out from the pipe update critical section
>   drm/i915: Change intel_pipe_update_{start,end}() calling convention
>   drm/i915: Extract intel_crtc_vblank_evade_scanlines()
>   drm/i915: Enable VRR later during fastsets
>   drm/i915: Adjust seamless_m_n flag behaviour
>   drm/i915: Optimize out redundant M/N updates
>   drm/i915: Relocate is_in_vrr_range()
>   drm/i915: Validate that the timings are within the VRR range
>   drm/i915: Disable VRR during seamless M/N changes
>   drm/i915: Update VRR parameters in fastset
>   drm/i915: Assert that VRR is off during vblank evasion if necessary
>   drm/i915: Implement transcoder LRR for TGL+
>
>  drivers/gpu/drm/i915/display/intel_atomic.c   |   2 +
>  drivers/gpu/drm/i915/display/intel_crtc.c | 110 --
>  drivers/gpu/drm/i915/display/intel_crtc.h |   6 +-
>  drivers/gpu/drm/i915/display/intel_display.c  | 135 ++
>  .../drm/i915/display/intel_display_device.h   |   1 +
>  .../drm/i915/display/intel_display_types.h|   5 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   |   2 +-
>  drivers/gpu/drm/i915/display/intel_panel.c|  17 +--
>  drivers/gpu/drm/i915/display/intel_vrr.c  |  18 ++-
>  drivers/gpu/drm/i915/display/intel_vrr.h  |   1 +
>  drivers/gpu/drm/i915/i915_reg.h   |   1 +
>  11 files changed, 212 insertions(+), 86 deletions(-)
>
> --
> 2.41.0
>


Re: [Intel-gfx] [PATCH v2 12/12] drm/i915: Implement transcoder LRR for TGL+

2023-09-20 Thread Manasi Navare
Hi Ville,

Quick question here on the use case and the trigger for the LRR case
which is within VRR range.
Could this perhaps be used if we had a virtual mode say 40Hz that now
falls in the VRR range (30 -120Hz) that is
exposed through the connector mode list and then if we do a modest to
40Hz that would make update_lrr = true within VRR and
hand adjust the vtotal to that exact value?
I am looking at adding this virtual mode to DRM soon, wondering if
this would be how the kernel would actual set the timings for it.

Regards
Manasi

On Mon, Sep 18, 2023 at 4:16 PM Manasi Navare  wrote:
>
> Thanks Ville for the respin, the changes look good now.
>
> Reviewed-by: Manasi Navare 
>
> Manasi
>
>
> On Fri, Sep 15, 2023 at 3:38 AM Ville Syrjala
>  wrote:
> >
> > From: Ville Syrjälä 
> >
> > Implement low refresh rate (LRR) where we change the vblank
> > length by hand as requested, but otherwise keep the timing
> > generator running in non-VRR mode (ie. fixed refresh rate).
> >
> > The panel itself must support VRR for this to work, and
> > only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that
> > we need to make the switch properly. The double buffer
> > latching happens at the start of transcoders undelayed
> > vblank. The other thing that we change is
> > TRANS_VBLANK.VBLANK_END but the hardware entirely ignores
> > that in DP mode. But I decided to keep writing it anyway
> > just to avoid more special cases in readout/state check.
> >
> > v2: Document that TRANS_VBLANK.VBLANK_END is ignored by
> > the hardware
> > v3: Reconcile with VRR fastset
> > Adjust update_lrr flag behaviour
> > Make sure timings stay within VRR range
> > v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi)
> > Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi)
> >
> > TODO: Hook LRR into the automatic DRRS downclocking stuff?
> >
> > Cc: Manasi Navare 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_atomic.c   |  1 +
> >  drivers/gpu/drm/i915/display/intel_crtc.c |  9 +--
> >  drivers/gpu/drm/i915/display/intel_display.c  | 60 +--
> >  .../drm/i915/display/intel_display_device.h   |  1 +
> >  .../drm/i915/display/intel_display_types.h|  3 +-
> >  drivers/gpu/drm/i915/display/intel_vrr.c  |  7 ++-
> >  6 files changed, 70 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > index aaddd8c0cfa0..5d18145da279 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > @@ -260,6 +260,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> >
> > crtc_state->update_pipe = false;
> > crtc_state->update_m_n = false;
> > +   crtc_state->update_lrr = false;
> > crtc_state->disable_lp_wm = false;
> > crtc_state->disable_cxsr = false;
> > crtc_state->update_wm_pre = false;
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c 
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index a39e31c1ca85..22e85fe7e8aa 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -495,7 +495,7 @@ static void intel_crtc_vblank_evade_scanlines(struct 
> > intel_atomic_state *state,
> > if (crtc->mode_flags & I915_MODE_FLAG_VRR) {
> > /* timing changes should happen with VRR disabled */
> > drm_WARN_ON(state->base.dev, 
> > intel_crtc_needs_modeset(new_crtc_state) ||
> > -   new_crtc_state->update_m_n);
> > +   new_crtc_state->update_m_n || 
> > new_crtc_state->update_lrr);
> >
> > if (intel_vrr_is_push_sent(crtc_state))
> > *vblank_start = 
> > intel_vrr_vmin_vblank_start(crtc_state);
> > @@ -511,10 +511,11 @@ static void intel_crtc_vblank_evade_scanlines(struct 
> > intel_atomic_state *state,
> > *max = *vblank_start - 1;
> >
> > /*
> > -* M/N is double buffered on the transcoder's undelayed vblank,
> > -* so with seamless M/N we must evade both vblanks.
> > +* M/N and TRANS_VTOTAL are double buffered on the transcoder's
> > +* undelayed vblank, so with seamless M/N and LRR we must evade
> > +* both vblanks.
> >  */
> > -   if (new_crtc_state->update_m_n)
> > +   if (new_crtc_state->update_m_n || new_crtc_state->update_lrr)
> > *min -= adjusted_mode->crtc_vblank_start - 
> > adjusted_mode->crtc_vdisplay;
> >  }
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index f0bb5c70ebfc..988558ccf794 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -928,7 +928,7 @@ static bool vrr_enabling(const struct intel_crtc_state 
> > *old_crtc_state,
> >  {
> >  

[Intel-gfx] ✗ Fi.CI.IGT: failure for Refactor i915 HDCP for XE (rev3)

2023-09-20 Thread Patchwork
== Series Details ==

Series: Refactor i915 HDCP for XE (rev3)
URL   : https://patchwork.freedesktop.org/series/123955/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13655_full -> Patchwork_123955v3_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_123955v3_full absolutely need 
to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_123955v3_full, please notify your bug team 
(lgci.bug.fil...@intel.com) 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_123955v3_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_selftest@drm_format_helper:
- shard-dg2:  NOTRUN -> [TIMEOUT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-dg2-11/igt@kms_selftest@drm_format_helper.html

  * igt@prime_busy@hang-wait@rcs0:
- shard-tglu: [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-tglu-6/igt@prime_busy@hang-w...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-tglu-5/igt@prime_busy@hang-w...@rcs0.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@api_intel_bb@blit-reloc-purge-cache:
- shard-dg2:  NOTRUN -> [SKIP][4] ([i915#8411])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-dg2-11/igt@api_intel...@blit-reloc-purge-cache.html

  * igt@debugfs_test@basic-hwmon:
- shard-tglu: NOTRUN -> [SKIP][5] ([i915#9318])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-tglu-10/igt@debugfs_t...@basic-hwmon.html

  * igt@drm_fdinfo@all-busy-check-all:
- shard-dg2:  NOTRUN -> [SKIP][6] ([i915#8414])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-dg2-11/igt@drm_fdi...@all-busy-check-all.html

  * igt@drm_fdinfo@busy-idle-check-all@ccs0:
- shard-mtlp: NOTRUN -> [SKIP][7] ([i915#8414]) +11 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-mtlp-6/igt@drm_fdinfo@busy-idle-check-...@ccs0.html

  * igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl:  [PASS][8] -> [FAIL][9] ([i915#7742])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html

  * igt@gem_basic@multigpu-create-close:
- shard-dg2:  NOTRUN -> [SKIP][10] ([i915#7697])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-dg2-11/igt@gem_ba...@multigpu-create-close.html

  * igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-lmem0-lmem0:
- shard-dg2:  [PASS][11] -> [INCOMPLETE][12] ([i915#7297])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-dg2-6/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-lmem0-lmem0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-dg2-6/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-lmem0-lmem0.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-mtlp: [PASS][13] -> [DMESG-WARN][14] ([i915#9262]) +2 other 
tests dmesg-warn
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/shard-mtlp-8/igt@gem_ctx_isolation@preservation...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-mtlp-4/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_ctx_persistence@engines-persistence:
- shard-snb:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1099]) +2 
other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-snb6/igt@gem_ctx_persiste...@engines-persistence.html

  * igt@gem_ctx_persistence@heartbeat-close:
- shard-dg2:  NOTRUN -> [SKIP][16] ([i915#8555])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-dg2-11/igt@gem_ctx_persiste...@heartbeat-close.html

  * igt@gem_ctx_persistence@saturated-hostile-nopreempt@vcs1:
- shard-mtlp: NOTRUN -> [SKIP][17] ([i915#5882]) +5 other tests skip
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-mtlp-6/igt@gem_ctx_persistence@saturated-hostile-nopree...@vcs1.html

  * igt@gem_ctx_sseu@invalid-args:
- shard-mtlp: NOTRUN -> [SKIP][18] ([i915#280])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/shard-mtl

Re: [Intel-gfx] [PATCH i-g-t v3 15/17] lib/kunit: Parse KTAP report from the main process thread

2023-09-20 Thread Mauro Carvalho Chehab
On Mon, 18 Sep 2023 15:43:05 +0200
Janusz Krzysztofik  wrote:

> There was an attempt to parse KTAP reports in the background while a kunit
> test module is loading.  However, since dynamic sub-subtests can be
> executed only from the main thread, that attempt was not quite successful,
> as IGT results from all executed kunit test cases were generated only
> after loading of kunit test module completed.
> 
> Now that the parser maintains its state and we can call it separately for
> each input line of a KTAP report, it is perfectly possible to call the
> parser from the main thread while the module is loading in the background,
> and convert results from kunit test cases immediately to results of IGT
> dynamic sub-subtests by running an igt_dynamic() section for each result
> as soon as returned by the parser.
> 
> Drop igt_ktap_parser() thread and execute igt_dynamic() for each kunit
> result obtained from igt_ktap_parse() called from the main thread.
> 
> Also, drop no longer needed functions from igt_ktap soruces.
> 
> v2: Interrupt blocking read() on modprobe failure.
> 
> Signed-off-by: Janusz Krzysztofik 

LGTM.

Acked-by: Mauro Carvalho Chehab 

> ---
>  lib/igt_kmod.c | 208 ++
>  lib/igt_ktap.c | 568 -
>  lib/igt_ktap.h |  22 --
>  3 files changed, 166 insertions(+), 632 deletions(-)
> 
> diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
> index 8fbd274ccf..7fa5b4aa80 100644
> --- a/lib/igt_kmod.c
> +++ b/lib/igt_kmod.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright © 2016 Intel Corporation
> + * Copyright © 2016-2023 Intel Corporation
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining a
>   * copy of this software and associated documentation files (the "Software"),
> @@ -26,7 +26,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
>  
>  #include "igt_aux.h"
>  #include "igt_core.h"
> @@ -748,20 +751,109 @@ void igt_kselftest_get_tests(struct kmod_module *kmod,
>  }
>  
>  struct modprobe_data {
> + pthread_t parent;
>   struct kmod_module *kmod;
>   const char *opts;
>   int err;
> + pthread_mutex_t lock;
> + pthread_t thread;
>  };
>  
>  static void *modprobe_task(void *arg)
>  {
>   struct modprobe_data *data = arg;
> + int err;
> +
> + err = modprobe(data->kmod, data->opts);
>  
> - data->err = modprobe(data->kmod, data->opts);
> + if (err) {
> + while (pthread_mutex_trylock(&data->lock) == EBUSY)
> + pthread_kill(data->parent, SIGCHLD);
> +
> + data->err = err;
> + pthread_mutex_unlock(&data->lock);
> + }
>  
>   return NULL;
>  }
>  
> +static void kunit_sigchld_handler(int signal)
> +{
> + return;
> +}
> +
> +static int kunit_kmsg_result_get(struct igt_list_head *results,
> +  struct modprobe_data *modprobe,
> +  int fd, struct igt_ktap_results *ktap)
> +{
> + struct sigaction sigchld = { .sa_handler = kunit_sigchld_handler, };
> + char record[BUF_LEN + 1], *buf;
> + unsigned long taints;
> + int ret;
> +
> + do {
> + if (igt_kernel_tainted(&taints))
> + return -ENOTRECOVERABLE;
> +
> + pthread_mutex_lock(&modprobe->lock);
> + if (!pthread_tryjoin_np(modprobe->thread, NULL) &&
> + modprobe->err) {
> + pthread_mutex_unlock(&modprobe->lock);
> + return modprobe->err;
> + }
> +
> + sigaction(SIGCHLD, &sigchld, NULL);
> + ret = read(fd, record, BUF_LEN);
> + sigaction(SIGCHLD, NULL, NULL);
> + pthread_mutex_unlock(&modprobe->lock);
> +
> + if (!ret)
> + return -ENODATA;
> + if (ret == -1)
> + return -errno;
> +
> + igt_assert_lt(0, ret);
> +
> + /* skip kmsg continuation lines */
> + if (igt_debug_on(*record == ' '))
> + continue;
> +
> + /* NULL-terminate the record */
> + record[ret] = '\0';
> +
> + /* detect start of log message, continue if not found */
> + buf = strchrnul(record, ';');
> + if (igt_debug_on(*buf == '\0'))
> + continue;
> + buf++;
> +
> + ret = igt_ktap_parse(buf, ktap);
> + if (ret != -EINPROGRESS)
> + break;
> + } while (igt_list_empty(results));
> +
> + return ret;
> +}
> +
> +static void kunit_result_free(struct igt_ktap_result *r,
> +   char **suite_name, char **case_name)
> +{
> + igt_list_del(&r->link);
> +
> + if (r->suite_name != *suite_name) {
> + free(*suite_name);
> + *suite_name = r->suite_name;
> + }
> +
> + if (r->case_name != *case_name) {
> + f

Re: [Intel-gfx] [PATCH v2] drm/i915/dsi: let HW maintain CLK_POST

2023-09-20 Thread Jani Nikula
On Thu, 14 Sep 2023, William Tseng  wrote:
> This change is to adjust TCLK-POST timing so DSI signaling can
> meet CTS specification.
>
> For clock lane, the TCLK-POST timing may be changed from
> 133.44 ns to 178.72 ns, which is greater than (60 ns+52*UI)
> and is conformed to the CTS standard.
>
> The computed UI is around 1.47 ns.
>
> v2: remove the change of HS-TRAIL.
>
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Vandita Kulkarni 
> Cc: Suraj Kandpal 
> Cc: Lee Shawn C 
> Signed-off-by: William Tseng 

Thanks, pushed to drm-intel-next.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ad6488e9c2b2..c4585e445198 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1822,7 +1822,7 @@ static void icl_dphy_param_init(struct intel_dsi 
> *intel_dsi)
>   u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
>   u32 ths_prepare_ns, tclk_trail_ns;
>   u32 hs_zero_cnt;
> - u32 tclk_pre_cnt, tclk_post_cnt;
> + u32 tclk_pre_cnt;
>  
>   tlpx_ns = intel_dsi_tlpx_ns(intel_dsi);
>  
> @@ -1869,15 +1869,6 @@ static void icl_dphy_param_init(struct intel_dsi 
> *intel_dsi)
>   tclk_pre_cnt = ICL_TCLK_PRE_CNT_MAX;
>   }
>  
> - /* tclk post count in escape clocks */
> - tclk_post_cnt = DIV_ROUND_UP(mipi_config->tclk_post, tlpx_ns);
> - if (tclk_post_cnt > ICL_TCLK_POST_CNT_MAX) {
> - drm_dbg_kms(&dev_priv->drm,
> - "tclk_post_cnt out of range (%d)\n",
> - tclk_post_cnt);
> - tclk_post_cnt = ICL_TCLK_POST_CNT_MAX;
> - }
> -
>   /* hs zero cnt in escape clocks */
>   hs_zero_cnt = DIV_ROUND_UP(mipi_config->ths_prepare_hszero -
>  ths_prepare_ns, tlpx_ns);
> @@ -1903,8 +1894,6 @@ static void icl_dphy_param_init(struct intel_dsi 
> *intel_dsi)
>  CLK_ZERO(clk_zero_cnt) |
>  CLK_PRE_OVERRIDE |
>  CLK_PRE(tclk_pre_cnt) |
> -CLK_POST_OVERRIDE |
> -CLK_POST(tclk_post_cnt) |
>  CLK_TRAIL_OVERRIDE |
>  CLK_TRAIL(trail_cnt));

-- 
Jani Nikula, Intel


Re: [Intel-gfx] [PATCH] drm/edid: Fixup h/vsync_end instead of h/vtotal

2023-09-20 Thread Jani Nikula
On Thu, 14 Sep 2023, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> There are some weird EDIDs floating around that have the sync
> pulse extending beyond the end of the blanking period.
>
> On the currently problemtic machine (HP Omni 120) EDID reports
> the following mode:
> "1600x900": 60 108000 1600 1780 1860 1800 900 910 913 1000 0x40 0x5
> which is then "corrected" to have htotal=1861 by the current drm_edid.c
> code.
>
> The fixup code was originally added in commit 7064fef56369 ("drm: work
> around EDIDs with bad htotal/vtotal values"). Googling around we end up in
> https://bugs.launchpad.net/ubuntu/hardy/+source/xserver-xorg-video-intel/+bug/297245
> where we find an EDID for a Dell Studio 15, which reports:
> (II) VESA(0): clock: 65.0 MHz   Image Size:  331 x 207 mm
> (II) VESA(0): h_active: 1280  h_sync: 1328  h_sync_end 1360 h_blank_end 1337 
> h_border: 0
> (II) VESA(0): v_active: 800  v_sync: 803  v_sync_end 809 v_blanking: 810 
> v_border: 0
>
> Note that if we use the hblank size (as opposed of the hsync_end)
> from the DTD to determine htotal we get exactly 60Hz refresh rate in
> both cases, whereas using hsync_end to determine htotal we get a
> slightly lower refresh rates. This makes me believe the using the
> hblank size is what was intended even in those cases.
>
> Also note that in case of the HP Onmi 120 the VBIOS boots with these:
>   crtc timings: 108000 1600 1780 1860 1800 900 910 913 1000, type: 0x40 
> flags: 0x5
> ie. it just blindly stuffs the bogus hsync_end and htotal from the DTD
> into the transcoder timing registers, and the display works. I believe
> the (at least more modern) hardware will automagically terminate the hsync
> pulse when the timing generator reaches htotal, which again points that we
> should use the hblank size to determine htotal. Unfortunatley the old bug
> reports for the Dell machines are extremely lacking in useful details so
> we have no idea what kind of timings the VBIOS programmed into the
> hardware :(
>
> Let's just flip this quirk around and reduce the length of the sync
> pulse instead of extending the blanking period. This at least seems
> to be the correct thing to do on more modern hardware. And if any
> issues crop up on older hardware we need to debug them properly.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8895
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 39dd3f694544..0c5563b4d21e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3497,11 +3497,11 @@ static struct drm_display_mode 
> *drm_mode_detailed(struct drm_connector *connecto
>   mode->vsync_end = mode->vsync_start + vsync_pulse_width;
>   mode->vtotal = mode->vdisplay + vblank;
>  
> - /* Some EDIDs have bogus h/vtotal values */
> + /* Some EDIDs have bogus h/vsync_end values */
>   if (mode->hsync_end > mode->htotal)
> - mode->htotal = mode->hsync_end + 1;
> + mode->hsync_end = mode->htotal;
>   if (mode->vsync_end > mode->vtotal)
> - mode->vtotal = mode->vsync_end + 1;
> + mode->vsync_end = mode->vtotal;

I wonder if we shouldn't debug log these to help our future selves?

Anyway,

Reviewed-by: Jani Nikula 


>  
>   drm_mode_do_interlace_quirk(mode, pt);

-- 
Jani Nikula, Intel


Re: [Intel-gfx] [PATCH] drm/i915: Remove unnecessary memory quiescing for aux inval

2023-09-20 Thread Matt Roper
On Wed, Sep 20, 2023 at 01:11:31PM +0200, Nirmoy Das wrote:
> i915 already does memory quiesce before signaling
> breadcrumb so remove extra memory quiescing for aux
> invalidation which can cause unnecessary side effects.

This explanation seems confusing to me.  If we've already performed the
necessary flushing and quiesced all cache<->memory traffic, then
performing another flush should just be a noop, right?  If we're seeing
side effects, then doesn't that imply that there was still something in
the cache that hadn't made its way to memory yet?

Is the breadcrumb code flushing all the necessary bits?  What about
PIPE_CONTROL_CCS_FLUSH?


Matt

> 
> Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before 
> invalidation")
> Cc: Jonathan Cavitt 
> Cc: Andi Shyti 
> Cc:  # v5.8+
> Cc: Andrzej Hajda 
> Cc: Tvrtko Ursulin 
> Cc: Matt Roper 
> Cc: Tejas Upadhyay 
> Cc: Lucas De Marchi 
> Cc: Prathap Kumar Valsan 
> Cc: Tapani Pälli 
> Cc: Mark Janes 
> Cc: Rodrigo Vivi 
> Signed-off-by: Nirmoy Das 
> ---
>  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 50 
>  1 file changed, 26 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 0143445dba83..5001670046a0 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -248,11 +248,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
> mode)
>  {
>   struct intel_engine_cs *engine = rq->engine;
>  
> - /*
> -  * On Aux CCS platforms the invalidation of the Aux
> -  * table requires quiescing memory traffic beforehand
> -  */
> - if (mode & EMIT_FLUSH || gen12_needs_ccs_aux_inv(engine)) {
> + if (mode & EMIT_FLUSH) {
>   u32 bit_group_0 = 0;
>   u32 bit_group_1 = 0;
>   int err;
> @@ -264,13 +260,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 
> mode)
>  
>   bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
>  
> - /*
> -  * When required, in MTL and beyond platforms we
> -  * need to set the CCS_FLUSH bit in the pipe control
> -  */
> - if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
> - bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
> -
>   bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
>   bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
>   bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
> @@ -800,14 +789,15 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
> *rq, u32 *cs)
>  {
>   struct drm_i915_private *i915 = rq->i915;
>   struct intel_gt *gt = rq->engine->gt;
> - u32 flags = (PIPE_CONTROL_CS_STALL |
> -  PIPE_CONTROL_TLB_INVALIDATE |
> -  PIPE_CONTROL_TILE_CACHE_FLUSH |
> -  PIPE_CONTROL_FLUSH_L3 |
> -  PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
> -  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> -  PIPE_CONTROL_DC_FLUSH_ENABLE |
> -  PIPE_CONTROL_FLUSH_ENABLE);
> + u32 bit_group_0 = PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
> + u32 bit_group_1 = (PIPE_CONTROL_CS_STALL |
> +PIPE_CONTROL_TLB_INVALIDATE |
> +PIPE_CONTROL_TILE_CACHE_FLUSH |
> +PIPE_CONTROL_FLUSH_L3 |
> +PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
> +PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> +PIPE_CONTROL_DC_FLUSH_ENABLE |
> +PIPE_CONTROL_FLUSH_ENABLE);
>  
>   /* Wa_14016712196 */
>   if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) || 
> IS_DG2(i915))
> @@ -817,14 +807,26 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
> *rq, u32 *cs)
>  
>   if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12, 
> 50))
>   /* Wa_1409600907 */
> - flags |= PIPE_CONTROL_DEPTH_STALL;
> + bit_group_1 |= PIPE_CONTROL_DEPTH_STALL;
>  
>   if (!HAS_3D_PIPELINE(rq->i915))
> - flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
> + bit_group_1 &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
>   else if (rq->engine->class == COMPUTE_CLASS)
> - flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
> + bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
> +
> + /*
> +  * On Aux CCS platforms the invalidation of the Aux
> +  * table requires quiescing memory traffic beforehand.
> +  * gen12_emit_fini_breadcrumb_rcs() does this for us as
> +  * all memory traffic has to be completed before we signal
> +  * the breadcrumb. In MTL and beyond platforms, we need to also
> +  * add CCS_FLUSH bit in the pipe control for that purpose.
> +  */
> +
> + if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
> + bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
>  
> -  

Re: [Intel-gfx] [PATCH i-g-t] tests/i915_pm_freq_api: Set min/max to expected values

2023-09-20 Thread Belgaumkar, Vinay



On 9/20/2023 7:07 AM, Rodrigo Vivi wrote:

On Mon, Sep 18, 2023 at 12:02:59PM -0700, Vinay Belgaumkar wrote:

A prior(rps) test leaves the system in a bad state causing failures
in the basic test.

Why?

What was the freq immediately before the failure that made the
machine to be busted and not accept the new freq request?

Maybe we should use this information to limit the freq requests
that we accept instead of workaround the test case. Otherwise
we are at risk of users selecting the bad freq that let " the
system in a bad state"...


i915_pm_rps (waitboost) test sets soft max_freq to some value less than 
RP0 and then fails. The restore on failure does not work properly as the 
test is not multitile capable(it sets the root sysfs entry instead of 
using the per tile entry). Then, the current test (i915_pm_freq_api --r 
basic-api) tries to set min_freq to RP0 as part of normal testing. This 
fails as soft_max is < RP0.


There is some non-trivial effort needed to convert i915_pm_rps to 
multitile, and this is a BAT failure, hence adding the quick fix to 
ensure the test runs with a good pre-environment.


Thanks,

Vinay.




Set min/max to expected values before running it.
Test will restore values at the end.

Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8670

Signed-off-by: Vinay Belgaumkar 
---
  tests/intel/i915_pm_freq_api.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/intel/i915_pm_freq_api.c b/tests/intel/i915_pm_freq_api.c
index 03bd0d05b..6018692a2 100644
--- a/tests/intel/i915_pm_freq_api.c
+++ b/tests/intel/i915_pm_freq_api.c
@@ -55,7 +55,11 @@ static void test_freq_basic_api(int dirfd, int gt)
rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
-   igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d", gt, rpn, rpe, rp0);
+   igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d\n", gt, rpn, rpe, rp0);
+
+   /* Set min/max to RPn, RP0 for baseline behavior */
+   igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+   igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0) > 0);
  
  	/*

 * Negative bound tests
@@ -170,7 +174,7 @@ igt_main
for_each_sysfs_gt_dirfd(i915, dirfd, gt) {
stash_min[gt] = get_freq(dirfd, RPS_MIN_FREQ_MHZ);
stash_max[gt] = get_freq(dirfd, RPS_MAX_FREQ_MHZ);
-   igt_debug("GT: %d, min: %d, max: %d", gt, 
stash_min[gt], stash_max[gt]);
+   igt_debug("GT: %d, min: %d, max: %d\n", gt, 
stash_min[gt], stash_max[gt]);
igt_pm_ignore_slpc_efficient_freq(i915, dirfd, true);
}
igt_install_exit_handler(restore_sysfs_freq);
--
2.38.1



[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,01/22] drm/i915/xelpdp: Add XE_LPDP_FEATURES (rev2)

2023-09-20 Thread Patchwork
== Series Details ==

Series: series starting with [CI,01/22] drm/i915/xelpdp: Add XE_LPDP_FEATURES 
(rev2)
URL   : https://patchwork.freedesktop.org/series/123938/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13656 -> Patchwork_123938v2


Summary
---

  **FAILURE**

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

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

Participating hosts (40 -> 39)
--

  Additional (1): fi-pnv-d510 
  Missing(2): fi-hsw-4770 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@perf:
- bat-jsl-3:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/bat-jsl-3/igt@i915_selftest@l...@perf.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123938v2/bat-jsl-3/igt@i915_selftest@l...@perf.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka:  [PASS][3] -> [DMESG-FAIL][4] ([i915#5334] / 
[i915#7872])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123938v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [PASS][5] -> [ABORT][6] ([i915#9262])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123938v2/bat-mtlp-8/igt@i915_selftest@l...@requests.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][7] -> [FAIL][8] ([IGT#3] / [i915#6121])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123938v2/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +31 other tests 
skip
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123938v2/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][10] ([i915#5334]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123938v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][12] ([i915#8668]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123938v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

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

  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
  [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#9262]: https://gitlab.freedesktop.org/drm/intel/issues/9262


Build changes
-

  * Linux: CI_DRM_13656 -> Patchwork_123938v2

  CI-20190529: 20190529
  CI_DRM_13656: c6b12d79c836cb83dc554bfefa0f5dc65e051197 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7493: 2517e42d612e0c1ca096acf8b5f6177f7ef4bce7 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_123938v2: c6b12d79c836cb83dc554bfefa0f5dc65e051197 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

f209ae6b7635 drm/i915/lnl: Start using CDCLK through PLL
e0fa2cffd49a drm/i915/xe2lpd: Add DC state support
aee3da4bc8f2 drm/i915/xe2lpd: Add display power well
aa0b61451036 drm/i915/lnl: Add CDCLK table
04d4ce9e2e44 drm/i915/lnl: Add gmbus/ddc support
a37c88870bd1 drm/i915/xe2

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,01/22] drm/i915/xelpdp: Add XE_LPDP_FEATURES (rev2)

2023-09-20 Thread Patchwork
== Series Details ==

Series: series starting with [CI,01/22] drm/i915/xelpdp: Add XE_LPDP_FEATURES 
(rev2)
URL   : https://patchwork.freedesktop.org/series/123938/
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.CHECKPATCH: warning for series starting with [CI,01/22] drm/i915/xelpdp: Add XE_LPDP_FEATURES (rev2)

2023-09-20 Thread Patchwork
== Series Details ==

Series: series starting with [CI,01/22] drm/i915/xelpdp: Add XE_LPDP_FEATURES 
(rev2)
URL   : https://patchwork.freedesktop.org/series/123938/
State : warning

== Summary ==

Error: dim checkpatch failed
90dd23f88c0a drm/i915/xelpdp: Add XE_LPDP_FEATURES
6330ee8e7216 drm/i915/lnl: Add display definitions
0df6b8dcc3bf drm/i915/xe2lpd: FBC is now supported on all pipes
47267c23e382 drm/i915/display: Remove FBC capability from fused off pipes
d2ab081dee5a drm/i915: Re-order if/else ladder in intel_detect_pch()
480cd983fb8a drm/i915/xe2lpd: Add fake PCH
9602282160c1 drm/i915/xe2lpd: Treat cursor plane as regular plane for DDB 
allocation
a6ddc8ff7c0b drm/i915/xe2lpd: Don't try to program PLANE_AUX_DIST
0aff2fb11f61 drm/i915/xe2lpd: Register DE_RRMR has been removed
89e5b5e66657 drm/i915/display: Fix style and conventions for DP AUX regs
929f8df603c8 drm/i915/display: Use _PICK_EVEN_2RANGES() in DP AUX regs
36459779ccd3 drm/i915/xe2lpd: Re-order DP AUX regs
-:88: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'aux_ch' - possible 
side-effects?
#88: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_regs.h:21:
+#define __xe2lpd_aux_ch_idx(aux_ch)
\
+   (aux_ch >= AUX_CH_USBC1 ? aux_ch : AUX_CH_USBC4 + 1 + aux_ch - AUX_CH_A)

-:88: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'aux_ch' may be better as 
'(aux_ch)' to avoid precedence issues
#88: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_regs.h:21:
+#define __xe2lpd_aux_ch_idx(aux_ch)
\
+   (aux_ch >= AUX_CH_USBC1 ? aux_ch : AUX_CH_USBC4 + 1 + aux_ch - AUX_CH_A)

-:104: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'aux_ch' - possible 
side-effects?
#104: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_regs.h:36:
+#define XELPDP_DP_AUX_CH_CTL(i915__, aux_ch)   
\
+   (DISPLAY_VER(i915__) >= 20 ?
\
+_XELPDP_DP_AUX_CH_CTL(__xe2lpd_aux_ch_idx(aux_ch)) :   
\
+_XELPDP_DP_AUX_CH_CTL(aux_ch))

-:121: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'aux_ch' - possible 
side-effects?
#121: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_regs.h:84:
+#define XELPDP_DP_AUX_CH_DATA(i915__, aux_ch, i)   
\
+   (DISPLAY_VER(i915__) >= 20 ?
\
+_XELPDP_DP_AUX_CH_DATA(__xe2lpd_aux_ch_idx(aux_ch), i) :   
\
+_XELPDP_DP_AUX_CH_DATA(aux_ch, i))

-:121: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i' - possible side-effects?
#121: FILE: drivers/gpu/drm/i915/display/intel_dp_aux_regs.h:84:
+#define XELPDP_DP_AUX_CH_DATA(i915__, aux_ch, i)   
\
+   (DISPLAY_VER(i915__) >= 20 ?
\
+_XELPDP_DP_AUX_CH_DATA(__xe2lpd_aux_ch_idx(aux_ch), i) :   
\
+_XELPDP_DP_AUX_CH_DATA(aux_ch, i))

total: 0 errors, 0 warnings, 5 checks, 92 lines checked
12dd53590a4e drm/i915/xe2lpd: Handle port AUX interrupts
986a5dc94cca drm/i915/xe2lpd: Read pin assignment from IOM
24cd21516592 drm/i915/xe2lpd: Enable odd size and panning for planar yuv
042f79b6681a drm/i915/xe2lpd: Add support for HPD
5a8fc38360d2 drm/i915/xe2lpd: Extend Wa_15010685871
1121ecaac4c2 drm/i915/lnl: Add gmbus/ddc support
713e5b5d6d95 drm/i915/lnl: Add CDCLK table
0dc346291447 drm/i915/xe2lpd: Add display power well
-:13: WARNING:TYPO_SPELLING: 'regiser' may be misspelled - perhaps 'register'?
#13: 
v2: Do not rmw as bit 31 is the only R/W bit in the regiser (Matt Roper)
^^^

total: 0 errors, 1 warnings, 0 checks, 113 lines checked
93d7ec0cdc80 drm/i915/xe2lpd: Add DC state support
-:41: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#41: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1565:
+I915_DECL_PW_DOMAINS(xe2lpd_pwdoms_dc_off,
+   POWER_DOMAIN_DC_OFF,

-:49: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#49: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1573:
+   .instances = &I915_PW_INSTANCES(

total: 0 errors, 0 warnings, 2 checks, 37 lines checked
57f5a13b3728 drm/i915/lnl: Start using CDCLK through PLL




Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/hdcp: Move common message filling function to its own file

2023-09-20 Thread Kandpal, Suraj

> Subject: Re: [PATCH v3 2/2] drm/i915/hdcp: Move common message filling
> function to its own file
> 
> On Wed, 20 Sep 2023, Suraj Kandpal  wrote:
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > new file mode 100644
> > index ..1096dd36823f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > @@ -0,0 +1,73 @@
> > +/* SPDX-License-Identifier: MIT */
> > +/*
> > + * Copyright © 2023 Intel Corporation  */
> > +
> > +#ifndef __INTEL_HDCP_GSC_MESSAGE_H__
> > +#define __INTEL_HDCP_GSC_MESSAGE_H__
> > +
> > +#include 
> 
> What does this header need from err.h?
> 

Ahh right this can be moved to intel_hdcp_gsc_message.c
I don’t know where my mind wanders off too :-[

Regards,
Suraj Kandpal

> BR,
> Jani.
> 
> > +#include 
> > +
> > +struct device;
> > +struct drm_i915_private;
> > +struct hdcp_port_data;
> > +struct hdcp2_ake_init;
> > +struct hdcp2_ake_send_cert;
> > +struct hdcp2_ake_no_stored_km;
> > +struct hdcp2_ake_send_hprime;
> > +struct hdcp2_ake_send_pairing_info;
> > +struct hdcp2_lc_init;
> > +struct hdcp2_lc_send_lprime;
> > +struct hdcp2_ske_send_eks;
> > +struct hdcp2_rep_send_receiverid_list; struct hdcp2_rep_send_ack;
> > +struct hdcp2_rep_stream_ready;
> > +
> > +ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8
> *msg_in,
> > +   size_t msg_in_len, u8 *msg_out,
> > +   size_t msg_out_len);
> > +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915); int
> > +intel_hdcp_gsc_initiate_session(struct device *dev, struct hdcp_port_data
> *data,
> > +   struct hdcp2_ake_init *ake_data); int
> > +intel_hdcp_gsc_verify_receiver_cert_prepare_km(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_ake_send_cert
> *rx_cert,
> > +  bool *km_stored,
> > +  struct hdcp2_ake_no_stored_km
> > +  *ek_pub_km,
> > +  size_t *msg_sz);
> > +int
> > +intel_hdcp_gsc_verify_hprime(struct device *dev, struct hdcp_port_data
> *data,
> > +struct hdcp2_ake_send_hprime *rx_hprime); int
> > +intel_hdcp_gsc_store_pairing_info(struct device *dev, struct
> hdcp_port_data *data,
> > + struct hdcp2_ake_send_pairing_info
> *pairing_info); int
> > +intel_hdcp_gsc_initiate_locality_check(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_lc_init *lc_init_data); int
> > +intel_hdcp_gsc_verify_lprime(struct device *dev, struct hdcp_port_data
> *data,
> > +struct hdcp2_lc_send_lprime *rx_lprime); int
> > +intel_hdcp_gsc_get_session_key(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_ske_send_eks *ske_data); int
> > +intel_hdcp_gsc_repeater_check_flow_prepare_ack(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct
> hdcp2_rep_send_receiverid_list
> > +  *rep_topology,
> > +  struct hdcp2_rep_send_ack
> > +  *rep_send_ack);
> > +int intel_hdcp_gsc_verify_mprime(struct device *dev,
> > +struct hdcp_port_data *data,
> > +struct hdcp2_rep_stream_ready
> *stream_ready); int
> > +intel_hdcp_gsc_enable_authentication(struct device *dev,
> > +struct hdcp_port_data *data);
> > +int
> > +intel_hdcp_gsc_close_session(struct device *dev, struct
> > +hdcp_port_data *data);
> > +
> > +#endif /* __INTEL_HDCP_GSC_MESSAGE_H__ */
> 
> --
> Jani Nikula, Intel


Re: [Intel-gfx] [PATCH 00/10] drm/i915/spi: spi access for discrete graphics

2023-09-20 Thread Mark Brown
On Wed, Sep 20, 2023 at 01:52:07PM +, Usyskin, Alexander wrote:

> I've tried to register spi controller with a spi-mem ops, but I can't find a 
> way to connect to mtd subsystem.
> I took spi-intel as example, which connects to spi-nor but it relies on JDEC 
> ID of flash to configure itself.

You should use the normal SPI device registration interfaces to register
whatever devices are connected to the SPI controller.  What in concrete
terms have you tried to do here and in what way did it not work?

> We have predefined set of operations unrelated to flash behind the controller.

This sounds like there's some sort of MFD rather than or as well as a
flash chip, or possibly multiple SPI devices?


signature.asc
Description: PGP signature


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Do not disable preemption for resets (rev2)

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Do not disable preemption for resets (rev2)
URL   : https://patchwork.freedesktop.org/series/120218/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13656 -> Patchwork_120218v2


Summary
---

  **FAILURE**

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

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

Participating hosts (40 -> 40)
--

  Additional (1): fi-pnv-d510 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@guc_multi_lrc:
- fi-kbl-soraka:  NOTRUN -> [ABORT][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120218v2/fi-kbl-soraka/igt@i915_selftest@live@guc_multi_lrc.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@lmem0:
- bat-dg2-9:  [PASS][2] -> [INCOMPLETE][3] ([i915#9275])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120218v2/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005:   [PASS][4] -> [DMESG-FAIL][5] ([i915#5334])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120218v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [PASS][6] -> [TIMEOUT][7] ([i915#6794] / [i915#7392])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120218v2/bat-rpls-1/igt@i915_selftest@l...@mman.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-1: [PASS][8] -> [WARN][9] ([i915#8747])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120218v2/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][10] -> [FAIL][11] ([IGT#3] / [i915#6121])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120218v2/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][12] ([i915#1845])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120218v2/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271]) +31 other tests 
skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120218v2/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

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

  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
  [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
  [i915#7392]: https://gitlab.freedesktop.org/drm/intel/issues/7392
  [i915#8747]: https://gitlab.freedesktop.org/drm/intel/issues/8747
  [i915#9275]: https://gitlab.freedesktop.org/drm/intel/issues/9275


Build changes
-

  * Linux: CI_DRM_13656 -> Patchwork_120218v2

  CI-20190529: 20190529
  CI_DRM_13656: c6b12d79c836cb83dc554bfefa0f5dc65e051197 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7493: 2517e42d612e0c1ca096acf8b5f6177f7ef4bce7 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_120218v2: c6b12d79c836cb83dc554bfefa0f5dc65e051197 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

bda747c13c89 drm/i915: Do not disable preemption for resets

== Logs ==

For more details see: 
https://intel-gfx-ci.01.o

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Lift runtime-pm acquire callbacks out of intel_wakeref.mutex

2023-09-20 Thread Nirmoy Das

Hi Jani,

On 9/20/2023 11:03 AM, Jani Nikula wrote:

On Mon, 18 Sep 2023, Nirmoy Das  wrote:

From: Chris Wilson 

When runtime pm is first woken, it will synchronously call the
registered callbacks for the device. These callbacks
may pull in their own forest of locks, which we do not want to
conflate with the intel_wakeref.mutex. A second minor benefit to
reducing the coverage of the mutex, is that it will reduce
contention for frequent sleeps and wakes (such as when being used
for soft-rc6).

Signed-off-by: Chris Wilson 
Signed-off-by: Nirmoy Das 
Reviewed-by: Andi Shyti 

Is this patch a dependency on the subsequent patches in the series? If
yes, what's the rationale?


When we do GGTT update with gpu request, we need to take pm wakeref for 
GT as well as for the engine and


without this patch/improvement there will be lockdep warning as we are 
not allowed to alloc memory with


vm->mutex held which can happen when the runtime pm woken up 1st.



If not, please submit separately. None of
this is is obvious in the commit messages.



So I would like to keep this patch in the series. I will add rationale 
in the cover letter and


resend with your below suggestions.


Thanks,

Nirmoy




---
  drivers/gpu/drm/i915/intel_wakeref.c | 43 ++--
  1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wakeref.c 
b/drivers/gpu/drm/i915/intel_wakeref.c
index 718f2f1b6174..af7b4cb5b4d7 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.c
+++ b/drivers/gpu/drm/i915/intel_wakeref.c
@@ -10,21 +10,11 @@
  #include "intel_wakeref.h"
  #include "i915_drv.h"
  
-static void rpm_get(struct intel_wakeref *wf)

-{
-   wf->wakeref = intel_runtime_pm_get(&wf->i915->runtime_pm);
-}
-
-static void rpm_put(struct intel_wakeref *wf)
-{
-   intel_wakeref_t wakeref = fetch_and_zero(&wf->wakeref);
-
-   intel_runtime_pm_put(&wf->i915->runtime_pm, wakeref);
-   INTEL_WAKEREF_BUG_ON(!wakeref);
-}
-
  int __intel_wakeref_get_first(struct intel_wakeref *wf)
  {
+   intel_wakeref_t wakeref = intel_runtime_pm_get(&wf->i915->runtime_pm);

No non-trivial function calls in the initializer please.


+   int err = 0;

Until now err was only for handling error returns. If it's also for
returning success, it should probably be named ret.


+
/*
 * Treat get/put as different subclasses, as we may need to run
 * the put callback from under the shrinker and do not want to
@@ -32,41 +22,50 @@ int __intel_wakeref_get_first(struct intel_wakeref *wf)
 * upon acquiring the wakeref.
 */
mutex_lock_nested(&wf->mutex, SINGLE_DEPTH_NESTING);
-   if (!atomic_read(&wf->count)) {
-   int err;
  
-		rpm_get(wf);

+   if (likely(!atomic_read(&wf->count))) {

Adding the likely should be a separate patch with rationale, not a
random drive-by change. (And maybe it just should not be added at all.)


+   INTEL_WAKEREF_BUG_ON(wf->wakeref);
+   wf->wakeref = fetch_and_zero(&wakeref);

fetch_and_zero() should just die. All it does here is make things more
confusing, not less. Please don't add new users.

The get and put helpers could probably stay, modified, to make this more
readable.

  
  		err = wf->ops->get(wf);

if (unlikely(err)) {
-   rpm_put(wf);
-   mutex_unlock(&wf->mutex);
-   return err;
+   wakeref = xchg(&wf->wakeref, 0);
+   wake_up_var(&wf->wakeref);

e.g. here this bit is duplicated in intel_wakeref_put_last().


+   goto unlock;
}
  
  		smp_mb__before_atomic(); /* release wf->count */

}
atomic_inc(&wf->count);
+   INTEL_WAKEREF_BUG_ON(atomic_read(&wf->count) <= 0);
+
+unlock:
mutex_unlock(&wf->mutex);
+   if (unlikely(wakeref))
+   intel_runtime_pm_put(&wf->i915->runtime_pm, wakeref);
  
-	INTEL_WAKEREF_BUG_ON(atomic_read(&wf->count) <= 0);

-   return 0;
+   return err;
  }
  
  static void intel_wakeref_put_last(struct intel_wakeref *wf)

  {
+   intel_wakeref_t wakeref = 0;
+
INTEL_WAKEREF_BUG_ON(atomic_read(&wf->count) <= 0);
if (unlikely(!atomic_dec_and_test(&wf->count)))
goto unlock;
  
  	/* ops->put() must reschedule its own release on error/deferral */

if (likely(!wf->ops->put(wf))) {
-   rpm_put(wf);
+   INTEL_WAKEREF_BUG_ON(!wf->wakeref);
+   wakeref = xchg(&wf->wakeref, 0);
wake_up_var(&wf->wakeref);
}
  
  unlock:

mutex_unlock(&wf->mutex);
+   if (wakeref)
+   intel_runtime_pm_put(&wf->i915->runtime_pm, wakeref);
  }
  
  void __intel_wakeref_put_last(struct intel_wakeref *wf, unsigned long flags)


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Do not disable preemption for resets (rev2)

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Do not disable preemption for resets (rev2)
URL   : https://patchwork.freedesktop.org/series/120218/
State : warning

== Summary ==

Error: dim checkpatch failed
8595cf4574a7 drm/i915: Do not disable preemption for resets
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit eb8d0f5af4ec ("drm/i915: Remove 
GPU reset dependence on struct_mutex")'
#14: 
eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex"),

-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 2caffbf11762 ("drm/i915: Revoke 
mmaps and prevent access to fence registers across reset")'
#15: 
but that never materialized and was soon removed in 2caffbf11762

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




[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add a note about fec_enable with 128b/132b

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915: add a note about fec_enable with 128b/132b
URL   : https://patchwork.freedesktop.org/series/123977/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13656 -> Patchwork_123977v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (40 -> 39)
--

  Additional (1): fi-pnv-d510 
  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [PASS][1] -> [ABORT][2] ([i915#9262])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [PASS][3] -> [FAIL][4] ([IGT#3] / [i915#6121])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +31 other tests 
skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][6] ([i915#5334]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13656/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123977v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

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

  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
  [i915#9262]: https://gitlab.freedesktop.org/drm/intel/issues/9262


Build changes
-

  * Linux: CI_DRM_13656 -> Patchwork_123977v1

  CI-20190529: 20190529
  CI_DRM_13656: c6b12d79c836cb83dc554bfefa0f5dc65e051197 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7493: 2517e42d612e0c1ca096acf8b5f6177f7ef4bce7 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_123977v1: c6b12d79c836cb83dc554bfefa0f5dc65e051197 @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

cd520ce14a27 drm/i915: add a note about fec_enable with 128b/132b

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/1] drm/i915/uapi: Enable L3 Bank Count Querying

2023-09-20 Thread Rodrigo Vivi
On Thu, Sep 14, 2023 at 11:32:49AM -0700, Jonathan Cavitt wrote:
> Extend the query ioctl to allow querying the count of the available L3
> Banks on a given engine.

Why do you need this? Who is using? Where's the pull request for the UMDs
and IGTs?

> 
> Signed-off-by: Jonathan Cavitt 
> ---

Please never send a cover letter with a stand-alone single patch.
Specially in this case where the cover letter is not bringing any
additional information. But even if you had enough information
it should be added here, below these '---', after the format-patch,
so it gets to the email without getting into the patch itself.

>  drivers/gpu/drm/i915/gt/intel_gt.c  | 26 +++
>  drivers/gpu/drm/i915/gt/intel_gt.h  |  3 +++
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h |  1 +
>  drivers/gpu/drm/i915/i915_query.c   | 34 +
>  include/uapi/drm/i915_drm.h | 15 ++-
>  5 files changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 449f0b7fc8434..865854c76c375 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -884,6 +884,32 @@ static int intel_gt_tile_setup(struct intel_gt *gt, 
> phys_addr_t phys_addr)
>   return 0;
>  }
>  
> +int intel_count_l3_banks(struct drm_i915_private *i915,
> +  struct intel_engine_cs *engine)
> +{
> + struct intel_gt *gt = engine->gt;
> + struct intel_uncore *uncore = gt->uncore;
> + intel_wakeref_t wakeref;
> + u32 count, store;
> +
> + /* L3 Banks not supported prior to version 12 */
> + if (GRAPHICS_VER(i915) < 12)
> + return -ENODEV;

-ENODEV is the best choice?

> +
> + if (IS_PONTEVECCHIO(i915)) {
> + with_intel_runtime_pm(uncore->rpm, wakeref)
> + store = intel_uncore_read(uncore, GEN10_MIRROR_FUSE3);
> + count = hweight32(REG_FIELD_GET(GEN12_MEML3_EN_MASK, store)) * 
> 4 *
> + hweight32(REG_FIELD_GET(XEHPC_GT_L3_MODE_MASK, store));
> + } else if (GRAPHICS_VER_FULL(i915) > IP_VER(12, 50)) {
> + count = hweight32(gt->info.mslice_mask) * 8;
> + } else {
> + count = hweight32(gt->info.l3bank_mask);
> + }
> +
> + return count;
> +}
> +
>  int intel_gt_probe_all(struct drm_i915_private *i915)
>  {
>   struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 239848bcb2a42..4a05443418efd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -161,6 +161,9 @@ static inline bool intel_gt_is_wedged(const struct 
> intel_gt *gt)
>   return unlikely(test_bit(I915_WEDGED, >->reset.flags));
>  }
>  
> +int intel_count_l3_banks(struct drm_i915_private *i915,
> +  struct intel_engine_cs *engine);
> +
>  int intel_gt_probe_all(struct drm_i915_private *i915);
>  int intel_gt_tiles_init(struct drm_i915_private *i915);
>  void intel_gt_release_all(struct drm_i915_private *i915);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index a00ff51c681d5..f148bf3dfd4b3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -569,6 +569,7 @@
>  #define  GEN10_MIRROR_FUSE3  _MMIO(0x9118)
>  #define   GEN10_L3BANK_PAIR_COUNT4

This seems to contradict what your comment above told about gen12+

>  #define   GEN10_L3BANK_MASK  0x0F
> +#define   XEHPC_GT_L3_MODE_MASK  REG_GENMASK(7, 4)
>  /* on Xe_HP the same fuses indicates mslices instead of L3 banks */
>  #define   GEN12_MAX_MSLICES  4
>  #define   GEN12_MEML3_EN_MASK0x0F
> diff --git a/drivers/gpu/drm/i915/i915_query.c 
> b/drivers/gpu/drm/i915/i915_query.c
> index 00871ef997920..bd3e68cf1bd10 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -10,6 +10,7 @@
>  #include "i915_perf.h"
>  #include "i915_query.h"
>  #include "gt/intel_engine_user.h"
> +#include "gt/intel_gt.h"
>  #include 
>  
>  static int copy_query_item(void *query_hdr, size_t query_sz,
> @@ -551,6 +552,38 @@ static int query_hwconfig_blob(struct drm_i915_private 
> *i915,
>   return hwconfig->size;
>  }
>  
> +static int
> +query_l3bank_count(struct drm_i915_private *i915,
> +struct drm_i915_query_item *query_item)
> +{
> + struct drm_i915_query_memory_regions __user *query_ptr =
> + u64_to_user_ptr(query_item->data_ptr);
> + struct i915_engine_class_instance classinstance;
> + struct intel_engine_cs *engine;
> + int count;
> +
> + if (query_item->length == 0)
> + return sizeof(count);
> +
> + classinstance = *((struct i915_engine_class_instance 
> *)&query_i

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing

2023-09-20 Thread Rob Clark
On Wed, Sep 20, 2023 at 7:35 AM Tvrtko Ursulin
 wrote:
>
>
> On 24/08/2023 12:35, Upadhyay, Tejas wrote:
> >> -Original Message-
> >> From: Intel-gfx  On Behalf Of 
> >> Tvrtko
> >> Ursulin
> >> Sent: Friday, July 7, 2023 6:32 PM
> >> To: Intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> >> Subject: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats
> >> printing
> >>
> >> From: Tvrtko Ursulin 
> >>
> >> Use the newly added drm_print_memory_stats helper to show memory
> >> utilisation of our objects in drm/driver specific fdinfo output.
> >>
> >> To collect the stats we walk the per memory regions object lists and
> >> accumulate object size into the respective drm_memory_stats categories.
> >>
> >> Objects with multiple possible placements are reported in multiple regions 
> >> for
> >> total and shared sizes, while other categories are counted only for the
> >> currently active region.
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> >> Cc: Aravind Iddamsetty 
> >> Cc: Rob Clark 
> >> ---
> >>   drivers/gpu/drm/i915/i915_drm_client.c | 85 ++
> >>   1 file changed, 85 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> >> b/drivers/gpu/drm/i915/i915_drm_client.c
> >> index ffccb6239789..5c77d6987d90 100644
> >> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> >> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> >> @@ -45,6 +45,89 @@ void __i915_drm_client_free(struct kref *kref)  }
> >>
> >>   #ifdef CONFIG_PROC_FS
> >> +static void
> >> +obj_meminfo(struct drm_i915_gem_object *obj,
> >> +struct drm_memory_stats stats[INTEL_REGION_UNKNOWN]) {
> >> +struct intel_memory_region *mr;
> >> +u64 sz = obj->base.size;
> >> +enum intel_region_id id;
> >> +unsigned int i;
> >> +
> >> +/* Attribute size and shared to all possible memory regions. */
> >> +for (i = 0; i < obj->mm.n_placements; i++) {
> >> +mr = obj->mm.placements[i];
> >> +id = mr->id;
> >> +
> >> +if (obj->base.handle_count > 1)
> >> +stats[id].shared += sz;
> >> +else
> >> +stats[id].private += sz;
> >> +}
> >> +
> >> +/* Attribute other categories to only the current region. */
> >> +mr = obj->mm.region;
> >> +if (mr)
> >> +id = mr->id;
> >> +else
> >> +id = INTEL_REGION_SMEM;
> >> +
> >> +if (!obj->mm.n_placements) {
> >> +if (obj->base.handle_count > 1)
> >> +stats[id].shared += sz;
> >> +else
> >> +stats[id].private += sz;
> >> +}
> >> +
> >> +if (i915_gem_object_has_pages(obj)) {
> >> +stats[id].resident += sz;
> >> +
> >> +if (!dma_resv_test_signaled(obj->base.resv,
> >> +dma_resv_usage_rw(true)))
> >
> > Should not DMA_RESV_USAGE_BOOKKEEP also considered active (why only "rw")? 
> > Some app is syncing with syncjobs and has added dma_fence with 
> > DMA_RESV_USAGE_BOOKKEEP during execbuf while that BO is busy on waiting on 
> > work!
>
> Hmm do we have a path which adds DMA_RESV_USAGE_BOOKKEEP usage in execbuf?
>
> Rob, any comments here? Given how I basically lifted the logic from
> 686b21b5f6ca ("drm: Add fdinfo memory stats"), does it sound plausible
> to upgrade the test against all fences?

Yes, I think so.. I don't have any use for BOOKKEEP so I hadn't considered it

BR,
-R


>
> Regards,
>
> Tvrtko
>
> >> +stats[id].active += sz;
> >> +else if (i915_gem_object_is_shrinkable(obj) &&
> >> + obj->mm.madv == I915_MADV_DONTNEED)
> >> +stats[id].purgeable += sz;
> >> +}
> >> +}
> >> +
> >> +static void show_meminfo(struct drm_printer *p, struct drm_file *file)
> >> +{
> >> +struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
> >> +struct drm_i915_file_private *fpriv = file->driver_priv;
> >> +struct i915_drm_client *client = fpriv->client;
> >> +struct drm_i915_private *i915 = fpriv->i915;
> >> +struct drm_i915_gem_object *obj;
> >> +struct intel_memory_region *mr;
> >> +struct list_head *pos;
> >> +unsigned int id;
> >> +
> >> +/* Public objects. */
> >> +spin_lock(&file->table_lock);
> >> +idr_for_each_entry (&file->object_idr, obj, id)
> >> +obj_meminfo(obj, stats);
> >> +spin_unlock(&file->table_lock);
> >> +
> >> +/* Internal objects. */
> >> +rcu_read_lock();
> >> +list_for_each_rcu(pos, &client->objects_list) {
> >> +obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
> >> + client_link));
> >> +if (!obj)
> >> +continue;
> >> +obj_meminfo(obj, stats);
> >> +i915_gem_object_put(obj);
> >> +}
> >> +rcu_read_unlock();
> >> +
> >> +for_each_memory_region(mr, i915, id)
> >> +  

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing

2023-09-20 Thread Tvrtko Ursulin



On 24/08/2023 12:35, Upadhyay, Tejas wrote:

-Original Message-
From: Intel-gfx  On Behalf Of Tvrtko
Ursulin
Sent: Friday, July 7, 2023 6:32 PM
To: Intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats
printing

From: Tvrtko Ursulin 

Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.

To collect the stats we walk the per memory regions object lists and
accumulate object size into the respective drm_memory_stats categories.

Objects with multiple possible placements are reported in multiple regions for
total and shared sizes, while other categories are counted only for the
currently active region.

Signed-off-by: Tvrtko Ursulin 
Cc: Aravind Iddamsetty 
Cc: Rob Clark 
---
  drivers/gpu/drm/i915/i915_drm_client.c | 85 ++
  1 file changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index ffccb6239789..5c77d6987d90 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -45,6 +45,89 @@ void __i915_drm_client_free(struct kref *kref)  }

  #ifdef CONFIG_PROC_FS
+static void
+obj_meminfo(struct drm_i915_gem_object *obj,
+   struct drm_memory_stats stats[INTEL_REGION_UNKNOWN]) {
+   struct intel_memory_region *mr;
+   u64 sz = obj->base.size;
+   enum intel_region_id id;
+   unsigned int i;
+
+   /* Attribute size and shared to all possible memory regions. */
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   mr = obj->mm.placements[i];
+   id = mr->id;
+
+   if (obj->base.handle_count > 1)
+   stats[id].shared += sz;
+   else
+   stats[id].private += sz;
+   }
+
+   /* Attribute other categories to only the current region. */
+   mr = obj->mm.region;
+   if (mr)
+   id = mr->id;
+   else
+   id = INTEL_REGION_SMEM;
+
+   if (!obj->mm.n_placements) {
+   if (obj->base.handle_count > 1)
+   stats[id].shared += sz;
+   else
+   stats[id].private += sz;
+   }
+
+   if (i915_gem_object_has_pages(obj)) {
+   stats[id].resident += sz;
+
+   if (!dma_resv_test_signaled(obj->base.resv,
+   dma_resv_usage_rw(true)))


Should not DMA_RESV_USAGE_BOOKKEEP also considered active (why only "rw")? Some 
app is syncing with syncjobs and has added dma_fence with DMA_RESV_USAGE_BOOKKEEP during 
execbuf while that BO is busy on waiting on work!


Hmm do we have a path which adds DMA_RESV_USAGE_BOOKKEEP usage in execbuf?

Rob, any comments here? Given how I basically lifted the logic from 
686b21b5f6ca ("drm: Add fdinfo memory stats"), does it sound plausible 
to upgrade the test against all fences?


Regards,

Tvrtko


+   stats[id].active += sz;
+   else if (i915_gem_object_is_shrinkable(obj) &&
+obj->mm.madv == I915_MADV_DONTNEED)
+   stats[id].purgeable += sz;
+   }
+}
+
+static void show_meminfo(struct drm_printer *p, struct drm_file *file)
+{
+   struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
+   struct drm_i915_file_private *fpriv = file->driver_priv;
+   struct i915_drm_client *client = fpriv->client;
+   struct drm_i915_private *i915 = fpriv->i915;
+   struct drm_i915_gem_object *obj;
+   struct intel_memory_region *mr;
+   struct list_head *pos;
+   unsigned int id;
+
+   /* Public objects. */
+   spin_lock(&file->table_lock);
+   idr_for_each_entry (&file->object_idr, obj, id)
+   obj_meminfo(obj, stats);
+   spin_unlock(&file->table_lock);
+
+   /* Internal objects. */
+   rcu_read_lock();
+   list_for_each_rcu(pos, &client->objects_list) {
+   obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
+client_link));
+   if (!obj)
+   continue;
+   obj_meminfo(obj, stats);
+   i915_gem_object_put(obj);
+   }
+   rcu_read_unlock();
+
+   for_each_memory_region(mr, i915, id)
+   drm_print_memory_stats(p,
+  &stats[id],
+  DRM_GEM_OBJECT_RESIDENT |
+  DRM_GEM_OBJECT_PURGEABLE,
+  mr->name);
+}
+
  static const char * const uabi_class_names[] = {
[I915_ENGINE_CLASS_RENDER] = "render",
[I915_ENGINE_CLASS_COPY] = "copy",
@@ -106,6 +189,8 @@ void i915_drm_client_fdinfo(struct drm_printer *p,
struct drm_file *file)
 *

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/i915_pm_freq_api: Set min/max to expected values

2023-09-20 Thread Riana Tauro




On 9/19/2023 12:32 AM, Vinay Belgaumkar wrote:

A prior(rps) test leaves the system in a bad state causing failures
in the basic test. Set min/max to expected values before running it.
Test will restore values at the end.

Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8670

Signed-off-by: Vinay Belgaumkar 

LGTM
Reviewed-by: Riana Tauro 

---
  tests/intel/i915_pm_freq_api.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/intel/i915_pm_freq_api.c b/tests/intel/i915_pm_freq_api.c
index 03bd0d05b..6018692a2 100644
--- a/tests/intel/i915_pm_freq_api.c
+++ b/tests/intel/i915_pm_freq_api.c
@@ -55,7 +55,11 @@ static void test_freq_basic_api(int dirfd, int gt)
rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
-   igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d", gt, rpn, rpe, rp0);
+   igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d\n", gt, rpn, rpe, rp0);
+
+   /* Set min/max to RPn, RP0 for baseline behavior */
+   igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
+   igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0) > 0);
  
  	/*

 * Negative bound tests
@@ -170,7 +174,7 @@ igt_main
for_each_sysfs_gt_dirfd(i915, dirfd, gt) {
stash_min[gt] = get_freq(dirfd, RPS_MIN_FREQ_MHZ);
stash_max[gt] = get_freq(dirfd, RPS_MAX_FREQ_MHZ);
-   igt_debug("GT: %d, min: %d, max: %d", gt, 
stash_min[gt], stash_max[gt]);
+   igt_debug("GT: %d, min: %d, max: %d\n", gt, 
stash_min[gt], stash_max[gt]);
igt_pm_ignore_slpc_efficient_freq(i915, dirfd, true);
}
igt_install_exit_handler(restore_sysfs_freq);


Re: [Intel-gfx] [PATCH i-g-t] tests/i915_pm_freq_api: Set min/max to expected values

2023-09-20 Thread Rodrigo Vivi
On Mon, Sep 18, 2023 at 12:02:59PM -0700, Vinay Belgaumkar wrote:
> A prior(rps) test leaves the system in a bad state causing failures
> in the basic test.

Why?

What was the freq immediately before the failure that made the
machine to be busted and not accept the new freq request?

Maybe we should use this information to limit the freq requests
that we accept instead of workaround the test case. Otherwise
we are at risk of users selecting the bad freq that let " the
system in a bad state"...

> Set min/max to expected values before running it.
> Test will restore values at the end.
> 
> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8670
> 
> Signed-off-by: Vinay Belgaumkar 
> ---
>  tests/intel/i915_pm_freq_api.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/intel/i915_pm_freq_api.c b/tests/intel/i915_pm_freq_api.c
> index 03bd0d05b..6018692a2 100644
> --- a/tests/intel/i915_pm_freq_api.c
> +++ b/tests/intel/i915_pm_freq_api.c
> @@ -55,7 +55,11 @@ static void test_freq_basic_api(int dirfd, int gt)
>   rpn = get_freq(dirfd, RPS_RPn_FREQ_MHZ);
>   rp0 = get_freq(dirfd, RPS_RP0_FREQ_MHZ);
>   rpe = get_freq(dirfd, RPS_RP1_FREQ_MHZ);
> - igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d", gt, rpn, rpe, rp0);
> + igt_debug("GT: %d, RPn: %d, RPe: %d, RP0: %d\n", gt, rpn, rpe, rp0);
> +
> + /* Set min/max to RPn, RP0 for baseline behavior */
> + igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0);
> + igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rp0) > 0);
>  
>   /*
>* Negative bound tests
> @@ -170,7 +174,7 @@ igt_main
>   for_each_sysfs_gt_dirfd(i915, dirfd, gt) {
>   stash_min[gt] = get_freq(dirfd, RPS_MIN_FREQ_MHZ);
>   stash_max[gt] = get_freq(dirfd, RPS_MAX_FREQ_MHZ);
> - igt_debug("GT: %d, min: %d, max: %d", gt, 
> stash_min[gt], stash_max[gt]);
> + igt_debug("GT: %d, min: %d, max: %d\n", gt, 
> stash_min[gt], stash_max[gt]);
>   igt_pm_ignore_slpc_efficient_freq(i915, dirfd, true);
>   }
>   igt_install_exit_handler(restore_sysfs_freq);
> -- 
> 2.38.1
> 


Re: [Intel-gfx] [PATCH v3 18/25] drm/i915/dp_mst: Add atomic state for all streams on pre-tgl platforms

2023-09-20 Thread Lisovskiy, Stanislav
On Wed, Sep 20, 2023 at 03:38:05PM +0300, Imre Deak wrote:
> On Wed, Sep 20, 2023 at 02:25:14PM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, Sep 20, 2023 at 01:59:53PM +0300, Ville Syrjälä wrote:
> > > On Wed, Sep 20, 2023 at 12:11:58PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Thu, Sep 14, 2023 at 10:26:52PM +0300, Imre Deak wrote:
> > > > > If an MST stream is modeset, its state must be checked along all the
> > > > > other streams on the same MST link, for instance to resolve a BW
> > > > > overallocation of a non-sink MST port or to make sure that the FEC is
> > > > > enabled/disabled the same way for all these streams.
> > > > > 
> > > > > To prepare for that this patch adds all the stream CRTCs to the atomic
> > > > > state and marks them for modeset similarly to tgl+ platforms. (If the
> > > > > state computation doesn't change the state the CRTC is switched back 
> > > > > to
> > > > > fastset mode.)
> > > > > 
> > > > > Signed-off-by: Imre Deak 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ---
> > > > >  1 file changed, 3 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > index c1fea894d3774..832e8b0e87e84 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > @@ -491,9 +491,6 @@ intel_dp_mst_atomic_master_trans_check(struct 
> > > > > intel_connector *connector,
> > > > >   struct intel_connector *connector_iter;
> > > > >   int ret = 0;
> > > > >  
> > > > > - if (DISPLAY_VER(dev_priv) < 12)
> > > > > - return  0;
> > > > > -
> > > > 
> > > > I'm just a bit concerned, why this check was initially added?
> > > > Probably there was a reason?
> > > 
> > > It's in the name of the function, which should be renamed if we're
> > > extending it beyond its original purpose.
> > 
> > Well, I would say this check could be "a bit" more descriptive.
> > Still, even if function name gets changed, we just remove the check, for the
> > function which was initially not even intended to be called for pre-tgl?
> 
> The change on tgl+ platforms is that all the MST streams go through a
> master transcoder, while on old platforms each stream has only its own
> transcoder. Hence on tgl+ all streams/CRTCs may need to be modeset, at
> least in the case the CRTC owning the master transcoder (for instance
> pipe A/transcoder A) is modeset. So on tgl+ here all CRTCs for a given
> MST topology is added to the state/marked for modeset.
> 
> pre-tgl this wasn't necessary, until the need to recalculate the BW
> requirement of each stream came up, as described in the commit log.
> 
> I can clarify the above in the commit log and rename the function
> accordingly, is that ok?

Yes, thank you for good explanation. I would may be also add some note to
actual function also, but up to you really.

Reviewed-by: Stanislav Lisovskiy 

> 
> > Why it became suitable now then? Or was it just wrong check?
> > 
> > Stan
> > 
> > > 
> > > > 
> > > > Stan
> > > > 
> > > > >   if (!intel_connector_needs_modeset(state, &connector->base))
> > > > >   return 0;
> > > > >  
> > > > > -- 
> > > > > 2.37.2
> > > > > 
> > > 
> > > -- 
> > > Ville Syrjälä
> > > Intel


Re: [Intel-gfx] [PATCH 00/10] drm/i915/spi: spi access for discrete graphics

2023-09-20 Thread Usyskin, Alexander
> > > > No SPI controllers are directly visible to userspace, some SPI devices
> > > > are selectively exposed but that needs to be explicitly requested and is
> > > > generally discouraged.
> 
> > > What are the options here? Explicitly request exception is the one.
> > > Any other way to add access to flash memory connected in such way?
> 
> > Register a spi controller with at least spi-mem ops, as suggested
> > previously, is the standard way I guess. If you're not willing to do
> > so, it must be justified, I guess?
> 
> Right, we already have a way of describing flash chips so that should be
> used to describe any flash chips.

Hi

I've tried to register spi controller with a spi-mem ops, but I can't find a 
way to connect to mtd subsystem.
I took spi-intel as example, which connects to spi-nor but it relies on JDEC ID 
of flash to configure itself.
We have predefined set of operations unrelated to flash behind the controller.
What is the right way to simulate the general operations?
Should I add dummy flash device? Or there is another option to connect 
spi-mem-only controller to mtd?
Or this is too much and warrant the exception to have direct MTD device?

-- 
Thanks,
Sasha





[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove unnecessary memory quiescing for aux inval

2023-09-20 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove unnecessary memory quiescing for aux inval
URL   : https://patchwork.freedesktop.org/series/123975/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13655 -> Patchwork_123975v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 33)
--

  Additional (3): fi-hsw-4770 bat-kbl-2 bat-adlm-1 
  Missing(8): bat-adlp-9 bat-dg2-9 fi-cfl-8700k fi-snb-2520m fi-cfl-guc 
fi-ivb-3770 fi-cfl-8109u fi-kbl-8809g 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-hsw-4770:NOTRUN -> [FAIL][1] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- bat-adlm-1: NOTRUN -> [SKIP][2] ([i915#3826])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html

  * igt@fbdev@eof:
- bat-adlm-1: NOTRUN -> [SKIP][3] ([i915#2582]) +3 other tests skip
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@fb...@eof.html

  * igt@fbdev@info:
- bat-kbl-2:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1849])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-kbl-2/igt@fb...@info.html
- bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#1849] / [i915#2582])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@fb...@info.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][6] ([fdo#109271]) +39 other tests 
skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html
- bat-adlm-1: NOTRUN -> [SKIP][7] ([i915#4613]) +3 other tests skip
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_tiled_pread_basic:
- bat-adlm-1: NOTRUN -> [SKIP][8] ([i915#3282])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@gem_tiled_pread_basic.html

  * igt@i915_pm_rps@basic-api:
- bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#6621])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@i915_pm_...@basic-api.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][10] -> [DMESG-FAIL][11] ([i915#5334])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [PASS][12] -> [ABORT][13] ([i915#9262])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#1845]) +17 other tests 
skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html

  * igt@kms_flip@basic-plain-flip:
- bat-adlm-1: NOTRUN -> [SKIP][15] ([i915#3637]) +3 other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@kms_f...@basic-plain-flip.html

  * igt@kms_force_connector_basic@force-load-detect:
- bat-adlm-1: NOTRUN -> [SKIP][16] ([fdo#109285])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_frontbuffer_tracking@basic:
- bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#1849])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-adlm-1/igt@kms_frontbuffer_track...@basic.html
- fi-bsw-nick:[PASS][18] -> [FAIL][19] ([i915#9276])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/fi-bsw-nick/igt@kms_frontbuffer_track...@basic.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/fi-bsw-nick/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][20] ([i915#1845]) +3 other tests skip
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123975v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_psr@cursor_plane_move:
- 

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

2023-09-20 Thread Gustavo Sousa
Quoting Shekhar Chauhan (2023-09-20 01:05:47-03:00)
>Drop UGM per set fragment threshold to 3
>
>BSpec: 54833
>Signed-off-by: Shekhar Chauhan 
>---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
> 2 files changed, 4 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
>b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
>index a00ff51c681d..f8ab99affa15 100644
>--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
>+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
>@@ -1227,6 +1227,7 @@
> #define EU_PERF_CNTL3PERF_REG(0xe758)
> 
> #define LSC_CHICKEN_BIT_0MCR_REG(0xe7c8)
>+#define   UGM_FRAGMENT_THRESHOLD_TO_3REG_BIT(58)

You probably want to define this as:

  #define   UGM_FRAGMENT_THRESHOLD_TO_3REG_BIT(58 - 32)

, and after the definition of LSC_CHICKEN_BIT_0_UDW.

See more below...

> #define   DISABLE_D8_D16_COASLESCEREG_BIT(30)
> #define   FORCE_1_SUB_MESSAGE_PER_FRAGMENTREG_BIT(15)
> #define LSC_CHICKEN_BIT_0_UDWMCR_REG(0xe7c8 + 4)
>diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
>b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>index 660d4f358eab..3f3977014ee7 100644
>--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>@@ -2914,6 +2914,9 @@ general_render_compute_wa_init(struct intel_engine_cs 
>*engine, struct i915_wa_li
>  * Wa_22015475538:dg2
>  */
> wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0_UDW, 
> DIS_CHAIN_2XSIMD8);
>+
>+/* Wa_18028616096:dg2 */
>+wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0, 
>UGM_FRAGMENT_THRESHOLD_TO_3);

...and here, use LSC_CHICKEN_BIT_0_UDW as target.

--
Gustavo Sousa

> }
> 
> if (IS_DG2_G11(i915)) {
>-- 
>2.34.1
>


Re: [Intel-gfx] [PATCH v2] drm: Update file owner during use

2023-09-20 Thread Christian König

Am 20.09.23 um 15:21 schrieb Tvrtko Ursulin:


On 28/08/2023 20:58, Rob Clark wrote:

On Wed, Jun 21, 2023 at 2:48 AM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

With the typical model where the display server opens the file 
descriptor

and then hands it over to the client(*), we were showing stale data in
debugfs.

Fix it by updating the drm_file->pid on ioctl access from a different
process.

The field is also made RCU protected to allow for lockless readers. 
Update

side is protected with dev->filelist_mutex.

Before:

$ cat /sys/kernel/debug/dri/0/clients
  command   pid dev master a   uid  magic
 Xorg  2344   0   y    y 0  0
 Xorg  2344   0   n    y 0  2
 Xorg  2344   0   n    y 0  3
 Xorg  2344   0   n    y 0  4

After:

$ cat /sys/kernel/debug/dri/0/clients
  command  tgid dev master a   uid  magic
 Xorg   830   0   y    y 0  0
    xfce4-session   880   0   n    y 0  1
    xfwm4   943   0   n    y 0  2
    neverball  1095   0   n    y 0  3

*)
More detailed and historically accurate description of various handover
implementation kindly provided by Emil Velikov:

"""
The traditional model, the server was the orchestrator managing the
primary device node. From the fd, to the master status and
authentication. But looking at the fd alone, this has varied across
the years.

IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open
fd(s) and reuse those whenever needed, DRI2 the client was responsible
for open() themselves and with DRI3 the fd was passed to the client.

Around the inception of DRI3 and systemd-logind, the latter became
another possible orchestrator. Whereby Xorg and Wayland compositors
could ask it for the fd. For various reasons (hysterical and genuine
ones) Xorg has a fallback path going the open(), whereas Wayland
compositors are moving to solely relying on logind... some never had
fallback even.

Over the past few years, more projects have emerged which provide
functionality similar (be that on API level, Dbus, or otherwise) to
systemd-logind.
"""

v2:
  * Fixed typo in commit text and added a fine historical explanation
    from Emil.

Signed-off-by: Tvrtko Ursulin 
Cc: "Christian König" 
Cc: Daniel Vetter 
Acked-by: Christian König 
Reviewed-by: Emil Velikov 


Reviewed-by: Rob Clark 
Tested-by: Rob Clark 


Thanks. If everyone else is happy with this approach I don't have the 
commit rights for drm-misc.


Going to take care of pushing this.

Regards,
Christian.



Regards,

Tvrtko




---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |  6 ++--
  drivers/gpu/drm/drm_auth.c  |  3 +-
  drivers/gpu/drm/drm_debugfs.c   | 10 ---
  drivers/gpu/drm/drm_file.c  | 40 
+++--

  drivers/gpu/drm/drm_ioctl.c |  3 ++
  drivers/gpu/drm/nouveau/nouveau_drm.c   |  5 +++-
  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c |  6 ++--
  include/drm/drm_file.h  | 13 ++--
  8 files changed, 71 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c

index 74055cba3dc9..849097dff02b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -963,6 +963,7 @@ static int amdgpu_debugfs_gem_info_show(struct 
seq_file *m, void *unused)

 list_for_each_entry(file, &dev->filelist, lhead) {
 struct task_struct *task;
 struct drm_gem_object *gobj;
+   struct pid *pid;
 int id;

 /*
@@ -972,8 +973,9 @@ static int amdgpu_debugfs_gem_info_show(struct 
seq_file *m, void *unused)
  * Therefore, we need to protect this ->comm access 
using RCU.

  */
 rcu_read_lock();
-   task = pid_task(file->pid, PIDTYPE_TGID);
-   seq_printf(m, "pid %8d command %s:\n", 
pid_nr(file->pid),

+   pid = rcu_dereference(file->pid);
+   task = pid_task(pid, PIDTYPE_TGID);
+   seq_printf(m, "pid %8d command %s:\n", pid_nr(pid),
    task ? task->comm : "");
 rcu_read_unlock();

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index cf92a9ae8034..2ed2585ded37 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -235,7 +235,8 @@ static int drm_new_set_master(struct drm_device 
*dev, struct drm_file *fpriv)

  static int
  drm_master_check_perm(struct drm_device *dev, struct drm_file 
*file_priv)

  {
-   if (file_priv->pid == task_pid(current) && 
file_priv->was_master)

+   if (file_priv->was_master &&
+   rcu_access_pointer(file_priv->pid) == task_pid(current))
 return 0;

 if (!capable(CAP_SYS_ADMIN

Re: [Intel-gfx] [PATCH v2] drm: Update file owner during use

2023-09-20 Thread Tvrtko Ursulin



On 28/08/2023 20:58, Rob Clark wrote:

On Wed, Jun 21, 2023 at 2:48 AM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

With the typical model where the display server opens the file descriptor
and then hands it over to the client(*), we were showing stale data in
debugfs.

Fix it by updating the drm_file->pid on ioctl access from a different
process.

The field is also made RCU protected to allow for lockless readers. Update
side is protected with dev->filelist_mutex.

Before:

$ cat /sys/kernel/debug/dri/0/clients
  command   pid dev master a   uid  magic
 Xorg  2344   0   yy 0  0
 Xorg  2344   0   ny 0  2
 Xorg  2344   0   ny 0  3
 Xorg  2344   0   ny 0  4

After:

$ cat /sys/kernel/debug/dri/0/clients
  command  tgid dev master a   uid  magic
 Xorg   830   0   yy 0  0
xfce4-session   880   0   ny 0  1
xfwm4   943   0   ny 0  2
neverball  1095   0   ny 0  3

*)
More detailed and historically accurate description of various handover
implementation kindly provided by Emil Velikov:

"""
The traditional model, the server was the orchestrator managing the
primary device node. From the fd, to the master status and
authentication. But looking at the fd alone, this has varied across
the years.

IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open
fd(s) and reuse those whenever needed, DRI2 the client was responsible
for open() themselves and with DRI3 the fd was passed to the client.

Around the inception of DRI3 and systemd-logind, the latter became
another possible orchestrator. Whereby Xorg and Wayland compositors
could ask it for the fd. For various reasons (hysterical and genuine
ones) Xorg has a fallback path going the open(), whereas Wayland
compositors are moving to solely relying on logind... some never had
fallback even.

Over the past few years, more projects have emerged which provide
functionality similar (be that on API level, Dbus, or otherwise) to
systemd-logind.
"""

v2:
  * Fixed typo in commit text and added a fine historical explanation
from Emil.

Signed-off-by: Tvrtko Ursulin 
Cc: "Christian König" 
Cc: Daniel Vetter 
Acked-by: Christian König 
Reviewed-by: Emil Velikov 


Reviewed-by: Rob Clark 
Tested-by: Rob Clark 


Thanks. If everyone else is happy with this approach I don't have the 
commit rights for drm-misc.


Regards,

Tvrtko




---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |  6 ++--
  drivers/gpu/drm/drm_auth.c  |  3 +-
  drivers/gpu/drm/drm_debugfs.c   | 10 ---
  drivers/gpu/drm/drm_file.c  | 40 +++--
  drivers/gpu/drm/drm_ioctl.c |  3 ++
  drivers/gpu/drm/nouveau/nouveau_drm.c   |  5 +++-
  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c |  6 ++--
  include/drm/drm_file.h  | 13 ++--
  8 files changed, 71 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 74055cba3dc9..849097dff02b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -963,6 +963,7 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file *m, 
void *unused)
 list_for_each_entry(file, &dev->filelist, lhead) {
 struct task_struct *task;
 struct drm_gem_object *gobj;
+   struct pid *pid;
 int id;

 /*
@@ -972,8 +973,9 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file *m, 
void *unused)
  * Therefore, we need to protect this ->comm access using RCU.
  */
 rcu_read_lock();
-   task = pid_task(file->pid, PIDTYPE_TGID);
-   seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid),
+   pid = rcu_dereference(file->pid);
+   task = pid_task(pid, PIDTYPE_TGID);
+   seq_printf(m, "pid %8d command %s:\n", pid_nr(pid),
task ? task->comm : "");
 rcu_read_unlock();

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index cf92a9ae8034..2ed2585ded37 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -235,7 +235,8 @@ static int drm_new_set_master(struct drm_device *dev, 
struct drm_file *fpriv)
  static int
  drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
  {
-   if (file_priv->pid == task_pid(current) && file_priv->was_master)
+   if (file_priv->was_master &&
+   rcu_access_pointer(file_priv->pid) == task_pid(current))
 return 0;

 if (!capable(CAP_SYS_ADMIN))
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4855230ba2c6..b46f5ceb24c6 100644
--- 

[Intel-gfx] ✓ Fi.CI.BAT: success for Refactor i915 HDCP for XE (rev3)

2023-09-20 Thread Patchwork
== Series Details ==

Series: Refactor i915 HDCP for XE (rev3)
URL   : https://patchwork.freedesktop.org/series/123955/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13655 -> Patchwork_123955v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (38 -> 38)
--

  Additional (1): fi-hsw-4770 
  Missing(1): fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@load:
- bat-adlp-6: [PASS][1] -> [DMESG-WARN][2] ([i915#1982] / 
[i915#8449])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/bat-adlp-6/igt@i915_module_l...@load.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/bat-adlp-6/igt@i915_module_l...@load.html

  * igt@i915_selftest@live@requests:
- bat-mtlp-8: [PASS][3] -> [ABORT][4] ([i915#9262])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/bat-mtlp-8/igt@i915_selftest@l...@requests.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +13 other tests 
skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-bsw-nick:[PASS][6] -> [FAIL][7] ([i915#9276])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/fi-bsw-nick/igt@kms_frontbuffer_track...@basic.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/fi-bsw-nick/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][8] ([i915#3546]) +2 other tests skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#1845])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1:
- fi-hsw-4770:NOTRUN -> [DMESG-WARN][10] ([i915#8841]) +6 other 
tests dmesg-warn
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/fi-hsw-4770/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-vga-1.html

  * igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1072]) +3 
other tests skip
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [DMESG-FAIL][12] ([i915#7699] / [i915#7913]) -> 
[PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@kms_chamelium_edid@hdmi-edid-read:
- {bat-dg2-13}:   [DMESG-WARN][14] ([i915#7952]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][16] ([IGT#3] / [i915#6121]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13655/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123955v3/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

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

  [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7952]: https://gitlab.freedesktop.org/drm/intel/issues/7952
  [i915#8449]: https://gitlab.freedesktop.org/d

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Refactor i915 HDCP for XE (rev3)

2023-09-20 Thread Patchwork
== Series Details ==

Series: Refactor i915 HDCP for XE (rev3)
URL   : https://patchwork.freedesktop.org/series/123955/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced 
symbol 'return'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced 
symbol 'mask'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced 
symbol 'p'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced 
symbol 'old'
+./include/asm-generic

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Refactor i915 HDCP for XE (rev3)

2023-09-20 Thread Patchwork
== Series Details ==

Series: Refactor i915 HDCP for XE (rev3)
URL   : https://patchwork.freedesktop.org/series/123955/
State : warning

== Summary ==

Error: dim checkpatch failed
004d02f4d754 drm/i915/hdcp: Move checks for gsc health status
39677cfad370 drm/i915/hdcp: Move common message filling function to its own file
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
  File "scripts/spdxcheck.py", line 6, in 
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:672: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#672: 
new file mode 100644

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




Re: [Intel-gfx] [PATCH v3 18/25] drm/i915/dp_mst: Add atomic state for all streams on pre-tgl platforms

2023-09-20 Thread Imre Deak
On Wed, Sep 20, 2023 at 02:25:14PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, Sep 20, 2023 at 01:59:53PM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 20, 2023 at 12:11:58PM +0300, Lisovskiy, Stanislav wrote:
> > > On Thu, Sep 14, 2023 at 10:26:52PM +0300, Imre Deak wrote:
> > > > If an MST stream is modeset, its state must be checked along all the
> > > > other streams on the same MST link, for instance to resolve a BW
> > > > overallocation of a non-sink MST port or to make sure that the FEC is
> > > > enabled/disabled the same way for all these streams.
> > > > 
> > > > To prepare for that this patch adds all the stream CRTCs to the atomic
> > > > state and marks them for modeset similarly to tgl+ platforms. (If the
> > > > state computation doesn't change the state the CRTC is switched back to
> > > > fastset mode.)
> > > > 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ---
> > > >  1 file changed, 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > index c1fea894d3774..832e8b0e87e84 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > @@ -491,9 +491,6 @@ intel_dp_mst_atomic_master_trans_check(struct 
> > > > intel_connector *connector,
> > > > struct intel_connector *connector_iter;
> > > > int ret = 0;
> > > >  
> > > > -   if (DISPLAY_VER(dev_priv) < 12)
> > > > -   return  0;
> > > > -
> > > 
> > > I'm just a bit concerned, why this check was initially added?
> > > Probably there was a reason?
> > 
> > It's in the name of the function, which should be renamed if we're
> > extending it beyond its original purpose.
> 
> Well, I would say this check could be "a bit" more descriptive.
> Still, even if function name gets changed, we just remove the check, for the
> function which was initially not even intended to be called for pre-tgl?

The change on tgl+ platforms is that all the MST streams go through a
master transcoder, while on old platforms each stream has only its own
transcoder. Hence on tgl+ all streams/CRTCs may need to be modeset, at
least in the case the CRTC owning the master transcoder (for instance
pipe A/transcoder A) is modeset. So on tgl+ here all CRTCs for a given
MST topology is added to the state/marked for modeset.

pre-tgl this wasn't necessary, until the need to recalculate the BW
requirement of each stream came up, as described in the commit log.

I can clarify the above in the commit log and rename the function
accordingly, is that ok?

> Why it became suitable now then? Or was it just wrong check?
> 
> Stan
> 
> > 
> > > 
> > > Stan
> > > 
> > > > if (!intel_connector_needs_modeset(state, &connector->base))
> > > > return 0;
> > > >  
> > > > -- 
> > > > 2.37.2
> > > > 
> > 
> > -- 
> > Ville Syrjälä
> > Intel


Re: [Intel-gfx] [PATCH] drm/i915: Remove unnecessary memory quiescing for aux inval

2023-09-20 Thread Tapani Pälli
I tested this first against tests that were failing for Mesa and it 
fixes all of the regressed cases (TGL LP). Also did a full run of all 
KHR-GLES31* and KHR-GLES32* test groups in the Khronos CTS suite, no 
regressions observed.


Tested-by: Tapani Pälli 


On 20.9.2023 14.11, Nirmoy Das wrote:

i915 already does memory quiesce before signaling
breadcrumb so remove extra memory quiescing for aux
invalidation which can cause unnecessary side effects.

Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before invalidation")
Cc: Jonathan Cavitt 
Cc: Andi Shyti 
Cc:  # v5.8+
Cc: Andrzej Hajda 
Cc: Tvrtko Ursulin 
Cc: Matt Roper 
Cc: Tejas Upadhyay 
Cc: Lucas De Marchi 
Cc: Prathap Kumar Valsan 
Cc: Tapani Pälli 
Cc: Mark Janes 
Cc: Rodrigo Vivi 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 50 
  1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 0143445dba83..5001670046a0 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -248,11 +248,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
  {
struct intel_engine_cs *engine = rq->engine;
  
-	/*

-* On Aux CCS platforms the invalidation of the Aux
-* table requires quiescing memory traffic beforehand
-*/
-   if (mode & EMIT_FLUSH || gen12_needs_ccs_aux_inv(engine)) {
+   if (mode & EMIT_FLUSH) {
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
int err;
@@ -264,13 +260,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
  
  		bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
  
-		/*

-* When required, in MTL and beyond platforms we
-* need to set the CCS_FLUSH bit in the pipe control
-*/
-   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
-   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
-
bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
@@ -800,14 +789,15 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs)
  {
struct drm_i915_private *i915 = rq->i915;
struct intel_gt *gt = rq->engine->gt;
-   u32 flags = (PIPE_CONTROL_CS_STALL |
-PIPE_CONTROL_TLB_INVALIDATE |
-PIPE_CONTROL_TILE_CACHE_FLUSH |
-PIPE_CONTROL_FLUSH_L3 |
-PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
-PIPE_CONTROL_DEPTH_CACHE_FLUSH |
-PIPE_CONTROL_DC_FLUSH_ENABLE |
-PIPE_CONTROL_FLUSH_ENABLE);
+   u32 bit_group_0 = PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+   u32 bit_group_1 = (PIPE_CONTROL_CS_STALL |
+  PIPE_CONTROL_TLB_INVALIDATE |
+  PIPE_CONTROL_TILE_CACHE_FLUSH |
+  PIPE_CONTROL_FLUSH_L3 |
+  PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+  PIPE_CONTROL_DC_FLUSH_ENABLE |
+  PIPE_CONTROL_FLUSH_ENABLE);
  
  	/* Wa_14016712196 */

if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) || 
IS_DG2(i915))
@@ -817,14 +807,26 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs)
  
  	if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))

/* Wa_1409600907 */
-   flags |= PIPE_CONTROL_DEPTH_STALL;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_STALL;
  
  	if (!HAS_3D_PIPELINE(rq->i915))

-   flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
else if (rq->engine->class == COMPUTE_CLASS)
-   flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+
+   /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand.
+* gen12_emit_fini_breadcrumb_rcs() does this for us as
+* all memory traffic has to be completed before we signal
+* the breadcrumb. In MTL and beyond platforms, we need to also
+* add CCS_FLUSH bit in the pipe control for that purpose.
+*/
+
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
  
-	cs = gen12_emit_pipe_control(cs, PIPE_CONTROL0_HDC_PIPELINE_FLUSH, flags, 0);

+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1, 0);
  
  	/*XXX: Look at gen8_emit_fini_breadcrumb_rcs */

cs = gen12_emit_ggtt_write_rcs(cs,


Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/hdcp: Move common message filling function to its own file

2023-09-20 Thread Jani Nikula
On Wed, 20 Sep 2023, Suraj Kandpal  wrote:
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h 
> b/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> new file mode 100644
> index ..1096dd36823f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> @@ -0,0 +1,73 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2023 Intel Corporation
> + */
> +
> +#ifndef __INTEL_HDCP_GSC_MESSAGE_H__
> +#define __INTEL_HDCP_GSC_MESSAGE_H__
> +
> +#include 

What does this header need from err.h?

BR,
Jani.

> +#include 
> +
> +struct device;
> +struct drm_i915_private;
> +struct hdcp_port_data;
> +struct hdcp2_ake_init;
> +struct hdcp2_ake_send_cert;
> +struct hdcp2_ake_no_stored_km;
> +struct hdcp2_ake_send_hprime;
> +struct hdcp2_ake_send_pairing_info;
> +struct hdcp2_lc_init;
> +struct hdcp2_lc_send_lprime;
> +struct hdcp2_ske_send_eks;
> +struct hdcp2_rep_send_receiverid_list;
> +struct hdcp2_rep_send_ack;
> +struct hdcp2_rep_stream_ready;
> +
> +ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8 *msg_in,
> + size_t msg_in_len, u8 *msg_out,
> + size_t msg_out_len);
> +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915);
> +int
> +intel_hdcp_gsc_initiate_session(struct device *dev, struct hdcp_port_data 
> *data,
> + struct hdcp2_ake_init *ake_data);
> +int
> +intel_hdcp_gsc_verify_receiver_cert_prepare_km(struct device *dev,
> +struct hdcp_port_data *data,
> +struct hdcp2_ake_send_cert 
> *rx_cert,
> +bool *km_stored,
> +struct hdcp2_ake_no_stored_km
> +*ek_pub_km,
> +size_t *msg_sz);
> +int
> +intel_hdcp_gsc_verify_hprime(struct device *dev, struct hdcp_port_data *data,
> +  struct hdcp2_ake_send_hprime *rx_hprime);
> +int
> +intel_hdcp_gsc_store_pairing_info(struct device *dev, struct hdcp_port_data 
> *data,
> +   struct hdcp2_ake_send_pairing_info 
> *pairing_info);
> +int
> +intel_hdcp_gsc_initiate_locality_check(struct device *dev,
> +struct hdcp_port_data *data,
> +struct hdcp2_lc_init *lc_init_data);
> +int
> +intel_hdcp_gsc_verify_lprime(struct device *dev, struct hdcp_port_data *data,
> +  struct hdcp2_lc_send_lprime *rx_lprime);
> +int intel_hdcp_gsc_get_session_key(struct device *dev,
> +struct hdcp_port_data *data,
> +struct hdcp2_ske_send_eks *ske_data);
> +int
> +intel_hdcp_gsc_repeater_check_flow_prepare_ack(struct device *dev,
> +struct hdcp_port_data *data,
> +struct 
> hdcp2_rep_send_receiverid_list
> +*rep_topology,
> +struct hdcp2_rep_send_ack
> +*rep_send_ack);
> +int intel_hdcp_gsc_verify_mprime(struct device *dev,
> +  struct hdcp_port_data *data,
> +  struct hdcp2_rep_stream_ready *stream_ready);
> +int intel_hdcp_gsc_enable_authentication(struct device *dev,
> +  struct hdcp_port_data *data);
> +int
> +intel_hdcp_gsc_close_session(struct device *dev, struct hdcp_port_data 
> *data);
> +
> +#endif /* __INTEL_HDCP_GSC_MESSAGE_H__ */

-- 
Jani Nikula, Intel


Re: [Intel-gfx] [PATCH] drm/i915: add a note about fec_enable with 128b/132b

2023-09-20 Thread Ville Syrjälä
On Wed, Sep 20, 2023 at 02:29:01PM +0300, Jani Nikula wrote:
> Add a note that fec_enable actually means FEC is to be enabled
> explicitly. 128b/132b always has FEC enabled, the driver doesn't need to
> enable it separately, and fec_enable will be false.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_display_types.h | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 3c54fe2bfddd..f781a9755a52 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1364,7 +1364,12 @@ struct intel_crtc_state {
>  
>   bool enhanced_framing;
>  
> - /* Forward Error correction State */
> + /*
> +  * Forward Error Correction.
> +  *
> +  * Note: This will be false for 128b/132b, which will always have FEC
> +  * enabled automatically.
> +  */
>   bool fec_enable;
>  
>   bool sdp_split_enable;
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check lane count when determining FEC support

2023-09-20 Thread Jani Nikula
On Wed, 20 Sep 2023, Ville Syrjälä  wrote:
> On Wed, Sep 20, 2023 at 12:23:34PM +0300, Jani Nikula wrote:
>> On Wed, 13 Sep 2023, Ville Syrjala  wrote:
>> > From: Ville Syrjälä 
>> >
>> > ICL doesn't support FEC with a x1 DP link. Make sure
>> > we don't try to enable FEC in such cases.
>> 
>> The question is, should we rather require x2 link for FEC?
>> 
>> I suppose x1 link with DSC+FEC is an unlikely scenario with our current
>> link bandwidth policy, so probably not a big deal.
>
> I think currently we just smash lane_count to max when using DSC.
> So doesn't really matter currently. But something to keep in mind 
> if/when we tune the policy.

The patch is actually a bit subtle. Or the existing code is.

The paths under intel_edp_dsc_compute_pipe_bpp() and
intel_dp_dsc_compute_pipe_bpp() *assume* FEC is enabled/disabled
depending on the case. They don't look at fec_enable. Any checks for
fec_enable in there would be late.

Let's say eDP gains the ability to do FEC. I don't even remember what
the DP spec says about that. But having to check for fec_enable would
trip over, because it's not initialized yet.

So the patch highlights one aspect to keep in mind, but a little bit
hides another point to keep in mind. Damned if you do, damned if you
don't...

BR,
Jani.


>
>> 
>> BR,
>> Jani.
>> 
>> >
>> > Requires a bit of reordering to make sure we've computed lane_count
>> > before checking it.
>> >
>> > Cc: Luca Coelho 
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/i915/display/intel_dp.c | 21 +++--
>> >  1 file changed, 11 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
>> > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > index 55ba6eeaa810..2cde8ac513bb 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > @@ -1363,7 +1363,8 @@ static bool intel_dp_source_supports_fec(struct 
>> > intel_dp *intel_dp,
>> >if (DISPLAY_VER(dev_priv) >= 12)
>> >return true;
>> >  
>> > -  if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A)
>> > +  if (DISPLAY_VER(dev_priv) == 11 &&
>> > +  encoder->port != PORT_A && pipe_config->lane_count != 1)
>> >return true;
>> >  
>> >return false;
>> > @@ -2105,15 +2106,6 @@ int intel_dp_dsc_compute_config(struct intel_dp 
>> > *intel_dp,
>> >&pipe_config->hw.adjusted_mode;
>> >int ret;
>> >  
>> > -  pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
>> > -  intel_dp_supports_fec(intel_dp, pipe_config);
>> > -
>> > -  if (!intel_dp_supports_dsc(intel_dp, pipe_config))
>> > -  return -EINVAL;
>> > -
>> > -  if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
>> > -  return -EINVAL;
>> > -
>> >/*
>> > * compute pipe bpp is set to false for DP MST DSC case
>> > * and compressed_bpp is calculated same time once
>> > @@ -2134,6 +2126,15 @@ int intel_dp_dsc_compute_config(struct intel_dp 
>> > *intel_dp,
>> >}
>> >}
>> >  
>> > +  pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
>> > +  intel_dp_supports_fec(intel_dp, pipe_config);
>> > +
>> > +  if (!intel_dp_supports_dsc(intel_dp, pipe_config))
>> > +  return -EINVAL;
>> > +
>> > +  if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
>> > +  return -EINVAL;
>> > +
>> >/* Calculate Slice count */
>> >if (intel_dp_is_edp(intel_dp)) {
>> >pipe_config->dsc.slice_count =
>> 
>> -- 
>> Jani Nikula, Intel

-- 
Jani Nikula, Intel


Re: [Intel-gfx] [PATCH] drm/i915: Do not disable preemption for resets

2023-09-20 Thread Tvrtko Ursulin



On 13/09/2023 18:04, Valentin Schneider wrote:

On Wed, 13 Sept 2023 at 18:48, Sebastian Andrzej Siewior
 wrote:


On 2023-07-05 10:30:25 [+0100], Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
preempt disable section over the hardware reset callback to prepare the
driver for being able to reset from atomic contexts.

…

This missed the v6.6 merge window. Has this been dropped for some reason
or just missed by chance? Can this be still applied, please?



Just an FYI, but I happened to be looking at an internal bug report
for exactly this
error site, so +1 here :)


It looks I failed to collect an r-b before the summer break and so it 
fell off my radar. Definitely want to merge it so I will try again.


Regards,

Tvrtko


Re: [Intel-gfx] [PATCH v3 17/25] drm/i915/dp_mst: Fix PBN calculation with FEC overhead

2023-09-20 Thread Imre Deak
On Wed, Sep 20, 2023 at 01:58:43PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 14, 2023 at 10:26:51PM +0300, Imre Deak wrote:
> > On 8b/10b MST links the PBN value for DSC streams must be calculated
> > accounting for the FEC overhead. The same applies to 8b/10b non-DSC
> > streams if there is another DSC stream on the same link. Fix up the PBN
> > calculation accordingly.
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 01291bbb44693..c1fea894d3774 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -110,7 +110,8 @@ static int intel_dp_mst_find_vcpi_slots_for_bpp(struct 
> > intel_encoder *encoder,
> >  
> > crtc_state->pbn = 
> > drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock,
> >bpp << 4,
> > -  false);
> > +  (dsc || 
> > crtc_state->fec_enable) &&
> > +   
> > !intel_dp_is_uhbr(crtc_state));
> 
> Why is this not simply 'fec_enable'?

For DSC it's enabled only after the link configuration is computed. I
can move that enabling from intel_dp_dsc_compute_config() earlier
instead.

> >  
> > slots = drm_dp_atomic_find_time_slots(state, &intel_dp->mst_mgr,
> >   connector->port,
> > -- 
> > 2.37.2
> 
> -- 
> Ville Syrjälä
> Intel


[Intel-gfx] [PATCH] drm/i915: add a note about fec_enable with 128b/132b

2023-09-20 Thread Jani Nikula
Add a note that fec_enable actually means FEC is to be enabled
explicitly. 128b/132b always has FEC enabled, the driver doesn't need to
enable it separately, and fec_enable will be false.

Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display_types.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3c54fe2bfddd..f781a9755a52 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1364,7 +1364,12 @@ struct intel_crtc_state {
 
bool enhanced_framing;
 
-   /* Forward Error correction State */
+   /*
+* Forward Error Correction.
+*
+* Note: This will be false for 128b/132b, which will always have FEC
+* enabled automatically.
+*/
bool fec_enable;
 
bool sdp_split_enable;
-- 
2.39.2



Re: [Intel-gfx] [PATCH v3 18/25] drm/i915/dp_mst: Add atomic state for all streams on pre-tgl platforms

2023-09-20 Thread Lisovskiy, Stanislav
On Wed, Sep 20, 2023 at 01:59:53PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 20, 2023 at 12:11:58PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Sep 14, 2023 at 10:26:52PM +0300, Imre Deak wrote:
> > > If an MST stream is modeset, its state must be checked along all the
> > > other streams on the same MST link, for instance to resolve a BW
> > > overallocation of a non-sink MST port or to make sure that the FEC is
> > > enabled/disabled the same way for all these streams.
> > > 
> > > To prepare for that this patch adds all the stream CRTCs to the atomic
> > > state and marks them for modeset similarly to tgl+ platforms. (If the
> > > state computation doesn't change the state the CRTC is switched back to
> > > fastset mode.)
> > > 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index c1fea894d3774..832e8b0e87e84 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -491,9 +491,6 @@ intel_dp_mst_atomic_master_trans_check(struct 
> > > intel_connector *connector,
> > >   struct intel_connector *connector_iter;
> > >   int ret = 0;
> > >  
> > > - if (DISPLAY_VER(dev_priv) < 12)
> > > - return  0;
> > > -
> > 
> > I'm just a bit concerned, why this check was initially added?
> > Probably there was a reason?
> 
> It's in the name of the function, which should be renamed if we're
> extending it beyond its original purpose.

Well, I would say this check could be "a bit" more descriptive.
Still, even if function name gets changed, we just remove the check, for the
function which was initially not even intended to be called for pre-tgl?
Why it became suitable now then? Or was it just wrong check?

Stan

> 
> > 
> > Stan
> > 
> > >   if (!intel_connector_needs_modeset(state, &connector->base))
> > >   return 0;
> > >  
> > > -- 
> > > 2.37.2
> > > 
> 
> -- 
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH] drm/i915: Fix aux invalidation with proper pipe_control flag

2023-09-20 Thread Nirmoy Das

Sent out https://patchwork.freedesktop.org/series/123975/

to replace this one as this not really fixing the issue.


Thanks,

Nirmoy

On 9/19/2023 2:19 PM, Tapani Pälli wrote:


On 19.9.2023 15.11, Andi Shyti wrote:

Hi Nirmoy,

On Tue, Sep 19, 2023 at 01:47:16PM +0200, Nirmoy Das wrote:

The suggestion from the spec is to do l3 fabric flush not L3 flush.

Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before
invalidation")

please put this in one line.


Cc: Jonathan Cavitt 
Cc: Andi Shyti 
Cc:  # v5.8+
Cc: Nirmoy Das 
Cc: Andrzej Hajda 
Cc: Tvrtko Ursulin 
Cc: Matt Roper 
Cc: Lucas De Marchi 
Cc: Tejas Upadhyay 
Cc: Prathap Kumar Valsan 
Signed-off-by: Nirmoy Das 

Reviewed-by: Andi Shyti 

and I believe

Tested-by: Tapani Pälli 


Yes, tested on TGL LP (0x9a49)!



Thanks,
Andi


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check lane count when determining FEC support

2023-09-20 Thread Ville Syrjälä
On Wed, Sep 20, 2023 at 12:23:34PM +0300, Jani Nikula wrote:
> On Wed, 13 Sep 2023, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > ICL doesn't support FEC with a x1 DP link. Make sure
> > we don't try to enable FEC in such cases.
> 
> The question is, should we rather require x2 link for FEC?
> 
> I suppose x1 link with DSC+FEC is an unlikely scenario with our current
> link bandwidth policy, so probably not a big deal.

I think currently we just smash lane_count to max when using DSC.
So doesn't really matter currently. But something to keep in mind 
if/when we tune the policy.

> 
> BR,
> Jani.
> 
> >
> > Requires a bit of reordering to make sure we've computed lane_count
> > before checking it.
> >
> > Cc: Luca Coelho 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 21 +++--
> >  1 file changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 55ba6eeaa810..2cde8ac513bb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1363,7 +1363,8 @@ static bool intel_dp_source_supports_fec(struct 
> > intel_dp *intel_dp,
> > if (DISPLAY_VER(dev_priv) >= 12)
> > return true;
> >  
> > -   if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A)
> > +   if (DISPLAY_VER(dev_priv) == 11 &&
> > +   encoder->port != PORT_A && pipe_config->lane_count != 1)
> > return true;
> >  
> > return false;
> > @@ -2105,15 +2106,6 @@ int intel_dp_dsc_compute_config(struct intel_dp 
> > *intel_dp,
> > &pipe_config->hw.adjusted_mode;
> > int ret;
> >  
> > -   pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
> > -   intel_dp_supports_fec(intel_dp, pipe_config);
> > -
> > -   if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> > -   return -EINVAL;
> > -
> > -   if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
> > -   return -EINVAL;
> > -
> > /*
> >  * compute pipe bpp is set to false for DP MST DSC case
> >  * and compressed_bpp is calculated same time once
> > @@ -2134,6 +2126,15 @@ int intel_dp_dsc_compute_config(struct intel_dp 
> > *intel_dp,
> > }
> > }
> >  
> > +   pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
> > +   intel_dp_supports_fec(intel_dp, pipe_config);
> > +
> > +   if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> > +   return -EINVAL;
> > +
> > +   if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
> > +   return -EINVAL;
> > +
> > /* Calculate Slice count */
> > if (intel_dp_is_edp(intel_dp)) {
> > pipe_config->dsc.slice_count =
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel


[Intel-gfx] [PATCH] drm/i915: Remove unnecessary memory quiescing for aux inval

2023-09-20 Thread Nirmoy Das
i915 already does memory quiesce before signaling
breadcrumb so remove extra memory quiescing for aux
invalidation which can cause unnecessary side effects.

Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before invalidation")
Cc: Jonathan Cavitt 
Cc: Andi Shyti 
Cc:  # v5.8+
Cc: Andrzej Hajda 
Cc: Tvrtko Ursulin 
Cc: Matt Roper 
Cc: Tejas Upadhyay 
Cc: Lucas De Marchi 
Cc: Prathap Kumar Valsan 
Cc: Tapani Pälli 
Cc: Mark Janes 
Cc: Rodrigo Vivi 
Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 50 
 1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 0143445dba83..5001670046a0 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -248,11 +248,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 {
struct intel_engine_cs *engine = rq->engine;
 
-   /*
-* On Aux CCS platforms the invalidation of the Aux
-* table requires quiescing memory traffic beforehand
-*/
-   if (mode & EMIT_FLUSH || gen12_needs_ccs_aux_inv(engine)) {
+   if (mode & EMIT_FLUSH) {
u32 bit_group_0 = 0;
u32 bit_group_1 = 0;
int err;
@@ -264,13 +260,6 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
 
bit_group_0 |= PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
 
-   /*
-* When required, in MTL and beyond platforms we
-* need to set the CCS_FLUSH bit in the pipe control
-*/
-   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
-   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
-
bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH;
bit_group_1 |= PIPE_CONTROL_FLUSH_L3;
bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
@@ -800,14 +789,15 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs)
 {
struct drm_i915_private *i915 = rq->i915;
struct intel_gt *gt = rq->engine->gt;
-   u32 flags = (PIPE_CONTROL_CS_STALL |
-PIPE_CONTROL_TLB_INVALIDATE |
-PIPE_CONTROL_TILE_CACHE_FLUSH |
-PIPE_CONTROL_FLUSH_L3 |
-PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
-PIPE_CONTROL_DEPTH_CACHE_FLUSH |
-PIPE_CONTROL_DC_FLUSH_ENABLE |
-PIPE_CONTROL_FLUSH_ENABLE);
+   u32 bit_group_0 = PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
+   u32 bit_group_1 = (PIPE_CONTROL_CS_STALL |
+  PIPE_CONTROL_TLB_INVALIDATE |
+  PIPE_CONTROL_TILE_CACHE_FLUSH |
+  PIPE_CONTROL_FLUSH_L3 |
+  PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+  PIPE_CONTROL_DC_FLUSH_ENABLE |
+  PIPE_CONTROL_FLUSH_ENABLE);
 
/* Wa_14016712196 */
if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) || 
IS_DG2(i915))
@@ -817,14 +807,26 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request 
*rq, u32 *cs)
 
if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12, 
50))
/* Wa_1409600907 */
-   flags |= PIPE_CONTROL_DEPTH_STALL;
+   bit_group_1 |= PIPE_CONTROL_DEPTH_STALL;
 
if (!HAS_3D_PIPELINE(rq->i915))
-   flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
else if (rq->engine->class == COMPUTE_CLASS)
-   flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+   bit_group_1 &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
+
+   /*
+* On Aux CCS platforms the invalidation of the Aux
+* table requires quiescing memory traffic beforehand.
+* gen12_emit_fini_breadcrumb_rcs() does this for us as
+* all memory traffic has to be completed before we signal
+* the breadcrumb. In MTL and beyond platforms, we need to also
+* add CCS_FLUSH bit in the pipe control for that purpose.
+*/
+
+   if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70))
+   bit_group_0 |= PIPE_CONTROL_CCS_FLUSH;
 
-   cs = gen12_emit_pipe_control(cs, PIPE_CONTROL0_HDC_PIPELINE_FLUSH, 
flags, 0);
+   cs = gen12_emit_pipe_control(cs, bit_group_0, bit_group_1, 0);
 
/*XXX: Look at gen8_emit_fini_breadcrumb_rcs */
cs = gen12_emit_ggtt_write_rcs(cs,
-- 
2.41.0



Re: [Intel-gfx] [PATCH 2/2] drm/i915: Require FEC for DSC on DP-MST

2023-09-20 Thread Ville Syrjälä
On Wed, Sep 20, 2023 at 12:20:51PM +0300, Jani Nikula wrote:
> On Wed, 13 Sep 2023, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > The current check just asserts that we need FEC to use DSC
> > with (non-eDP) DP-SST. But MST also needs FEC for DSC. Just
> > check for !eDP instead to cover all the cases correctly.
> 
> 128b/132b won't have crtc->fec_enable set, as it's part of channel
> encoding. We don't need to explicitly enable it in hardware, the
> 128b/132b bandwidth computations take it into account in the equation,
> but we can't skip DSC based on !crtc_state->fec_enable either.

Hmm. Right. I suppose we need a uhbr check here as well then.

> 
> BR,
> Jani.
> 
> 
> >
> > Cc: Luca Coelho 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 2cde8ac513bb..41f180f2879e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1380,7 +1380,7 @@ static bool intel_dp_supports_fec(struct intel_dp 
> > *intel_dp,
> >  static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> >   const struct intel_crtc_state *crtc_state)
> >  {
> > -   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP) && 
> > !crtc_state->fec_enable)
> > +   if (!intel_dp_is_edp(intel_dp) && !crtc_state->fec_enable)
> > return false;
> >  
> > return intel_dsc_source_support(crtc_state) &&
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel


  1   2   >