date:20231114

Re: [Intel-gfx] [RFC 3/3] drm/i915: Compute CMRR and calculate vtotal

2023-11-14 Thread Ville Syrjälä

On Wed, Nov 15, 2023 at 12:00:54PM +0530, Mitul Golani wrote:
> Compute Fixed Average Vtotal/CMRR with resepect to
> userspace VRR enablement. Also calculate required
> parameters in case of CMRR is  enabled. During
> intel_vrr_compute_config, CMRR is getting enabled
> based on userspace has enabled Adaptive Sync Vtotal
> mode (Legacy VRR) or not.
> 
> Signed-off-by: Mitul Golani 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>  .../drm/i915/display/intel_display_device.h   |  1 +
>  drivers/gpu/drm/i915/display/intel_vrr.c  | 81 +--
>  3 files changed, 78 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f5a69309e65a..d61790f8ebb4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5479,6 +5479,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
> *current_config,
>   PIPE_CONF_CHECK_I(vrr.guardband);
>   PIPE_CONF_CHECK_LLI(cmrr.cmrr_m);
>   PIPE_CONF_CHECK_LLI(cmrr.cmrr_n);
> + PIPE_CONF_CHECK_BOOL(cmrr.enable);
>   }
>  
>  #undef PIPE_CONF_CHECK_X
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h 
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index 4299cc452e05..66cbc3a6bbe8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -68,6 +68,7 @@ struct drm_printer;
>  #define HAS_TRANSCODER(i915, trans)  
> ((DISPLAY_RUNTIME_INFO(i915)->cpu_transcoder_mask & \
> BIT(trans)) != 0)
>  #define HAS_VRR(i915)(DISPLAY_VER(i915) >= 11)
> +#define HAS_CMRR(i915)   (DISPLAY_VER(i915) >= 20)
>  #define INTEL_NUM_PIPES(i915)
> (hweight8(DISPLAY_RUNTIME_INFO(i915)->pipe_mask))
>  #define I915_HAS_HOTPLUG(i915)   
> (DISPLAY_INFO(i915)->has_hotplug)
>  #define OVERLAY_NEEDS_PHYSICAL(i915) 
> (DISPLAY_INFO(i915)->overlay_needs_physical)
> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
> b/drivers/gpu/drm/i915/display/intel_vrr.c
> index 1e33661062b3..4a056a71b68d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
> @@ -105,6 +105,52 @@ int intel_vrr_vmax_vblank_start(const struct 
> intel_crtc_state *crtc_state)
>   return crtc_state->vrr.vmax - intel_vrr_vblank_exit_length(crtc_state);
>  }
>  
> +static int
> +is_cmrr_frac_required(struct intel_crtc_state *crtc_state)
> +{
> + int target_refresh_k, actual_refresh_k;
> + struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
> +
> + target_refresh_k = drm_mode_vrefresh(adjusted_mode) * 1000;

That is just your 'actual_refresh' rounded to the nearest
integer. It is *not* any kind of target refresh rate.

> + actual_refresh_k = DIV_ROUND_UP(adjusted_mode->crtc_clock * 1000,
> + adjusted_mode->crtc_htotal) * 1000;
> + actual_refresh_k /= adjusted_mode->crtc_vtotal;
> +
> + if (actual_refresh_k == target_refresh_k)
> + return false;
> +
> + return true;
> +}
> +
> +static unsigned int
> +cmrr_get_vtotal(struct intel_crtc_state *crtc_state)
> +{
> + unsigned int muliplierM = 1, muliplierN = 1, vtotal;
> + unsigned int actual_refresh_rate, desired_refresh_rate;
> + unsigned long long actual_pixel_rate;
> + struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
> +
> + actual_refresh_rate = DIV_ROUND_UP(adjusted_mode->crtc_clock * 1000,
> +adjusted_mode->crtc_htotal) * 1000;
> + actual_refresh_rate /= adjusted_mode->crtc_vtotal;
> + desired_refresh_rate = drm_mode_vrefresh(adjusted_mode);
> + actual_pixel_rate = actual_refresh_rate * adjusted_mode->crtc_vtotal;
> + actual_pixel_rate = (actual_pixel_rate * adjusted_mode->crtc_htotal) / 
> 1000;
> +
> + if (is_cmrr_frac_required(crtc_state)) {
> + muliplierM = 1001;
> + muliplierN = 1000;
> + }
> +
> + crtc_state->cmrr.cmrr_n = DIV_ROUND_UP(desired_refresh_rate *
> + adjusted_mode->crtc_htotal * muliplierN, muliplierM) * 
> muliplierN;
> + vtotal = DIV_ROUND_UP(actual_pixel_rate * muliplierN, 
> crtc_state->cmrr.cmrr_n);
> + crtc_state->cmrr.cmrr_m =
> + (actual_pixel_rate * muliplierM) % crtc_state->cmrr.cmrr_n;
> +
> + return vtotal;
> +}
> +
>  void
>  intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
>struct drm_connector_state *conn_state)
> @@ -149,6 +195,27 @@ intel_vrr_compute_config(struct intel_crtc_state 
> *crtc_state,
>  
>   crtc_state->vrr.flipline = crtc_state->vrr.vmin + 1;
>  
> + /*
> +  * When panel is VRR capable and userspace has
> +  * not enabled adaptive

[Intel-gfx] [RFC 3/3] drm/i915: Compute CMRR and calculate vtotal

2023-11-14 Thread Mitul Golani

Compute Fixed Average Vtotal/CMRR with resepect to
userspace VRR enablement. Also calculate required
parameters in case of CMRR is  enabled. During
intel_vrr_compute_config, CMRR is getting enabled
based on userspace has enabled Adaptive Sync Vtotal
mode (Legacy VRR) or not.

Signed-off-by: Mitul Golani 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  1 +
 .../drm/i915/display/intel_display_device.h   |  1 +
 drivers/gpu/drm/i915/display/intel_vrr.c  | 81 +--
 3 files changed, 78 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f5a69309e65a..d61790f8ebb4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5479,6 +5479,7 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_I(vrr.guardband);
PIPE_CONF_CHECK_LLI(cmrr.cmrr_m);
PIPE_CONF_CHECK_LLI(cmrr.cmrr_n);
+   PIPE_CONF_CHECK_BOOL(cmrr.enable);
}
 
 #undef PIPE_CONF_CHECK_X
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h 
b/drivers/gpu/drm/i915/display/intel_display_device.h
index 4299cc452e05..66cbc3a6bbe8 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.h
+++ b/drivers/gpu/drm/i915/display/intel_display_device.h
@@ -68,6 +68,7 @@ struct drm_printer;
 #define HAS_TRANSCODER(i915, trans)
((DISPLAY_RUNTIME_INFO(i915)->cpu_transcoder_mask & \
  BIT(trans)) != 0)
 #define HAS_VRR(i915)  (DISPLAY_VER(i915) >= 11)
+#define HAS_CMRR(i915) (DISPLAY_VER(i915) >= 20)
 #define INTEL_NUM_PIPES(i915)  
(hweight8(DISPLAY_RUNTIME_INFO(i915)->pipe_mask))
 #define I915_HAS_HOTPLUG(i915) (DISPLAY_INFO(i915)->has_hotplug)
 #define OVERLAY_NEEDS_PHYSICAL(i915)   
(DISPLAY_INFO(i915)->overlay_needs_physical)
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 1e33661062b3..4a056a71b68d 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -105,6 +105,52 @@ int intel_vrr_vmax_vblank_start(const struct 
intel_crtc_state *crtc_state)
return crtc_state->vrr.vmax - intel_vrr_vblank_exit_length(crtc_state);
 }
 
+static int
+is_cmrr_frac_required(struct intel_crtc_state *crtc_state)
+{
+   int target_refresh_k, actual_refresh_k;
+   struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
+
+   target_refresh_k = drm_mode_vrefresh(adjusted_mode) * 1000;
+   actual_refresh_k = DIV_ROUND_UP(adjusted_mode->crtc_clock * 1000,
+   adjusted_mode->crtc_htotal) * 1000;
+   actual_refresh_k /= adjusted_mode->crtc_vtotal;
+
+   if (actual_refresh_k == target_refresh_k)
+   return false;
+
+   return true;
+}
+
+static unsigned int
+cmrr_get_vtotal(struct intel_crtc_state *crtc_state)
+{
+   unsigned int muliplierM = 1, muliplierN = 1, vtotal;
+   unsigned int actual_refresh_rate, desired_refresh_rate;
+   unsigned long long actual_pixel_rate;
+   struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
+
+   actual_refresh_rate = DIV_ROUND_UP(adjusted_mode->crtc_clock * 1000,
+  adjusted_mode->crtc_htotal) * 1000;
+   actual_refresh_rate /= adjusted_mode->crtc_vtotal;
+   desired_refresh_rate = drm_mode_vrefresh(adjusted_mode);
+   actual_pixel_rate = actual_refresh_rate * adjusted_mode->crtc_vtotal;
+   actual_pixel_rate = (actual_pixel_rate * adjusted_mode->crtc_htotal) / 
1000;
+
+   if (is_cmrr_frac_required(crtc_state)) {
+   muliplierM = 1001;
+   muliplierN = 1000;
+   }
+
+   crtc_state->cmrr.cmrr_n = DIV_ROUND_UP(desired_refresh_rate *
+   adjusted_mode->crtc_htotal * muliplierN, muliplierM) * 
muliplierN;
+   vtotal = DIV_ROUND_UP(actual_pixel_rate * muliplierN, 
crtc_state->cmrr.cmrr_n);
+   crtc_state->cmrr.cmrr_m =
+   (actual_pixel_rate * muliplierM) % crtc_state->cmrr.cmrr_n;
+
+   return vtotal;
+}
+
 void
 intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
 struct drm_connector_state *conn_state)
@@ -149,6 +195,27 @@ intel_vrr_compute_config(struct intel_crtc_state 
*crtc_state,
 
crtc_state->vrr.flipline = crtc_state->vrr.vmin + 1;
 
+   /*
+* When panel is VRR capable and userspace has
+* not enabled adaptive sync mode then Fixed Average
+* Vtotal mode should be enabled.
+*/
+   if (crtc_state->uapi.vrr_enabled) {
+   crtc_state->vrr.enable = true;
+   if (HAS_CMRR(i915))
+   crtc_state->cmrr.enable = false;
+   crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
+   } else {
+

[Intel-gfx] [RFC 2/3] drm/i915: Add Enable/Disable for CMRR based on VRR state

2023-11-14 Thread Mitul Golani

Add CMRR/Fixed Average Vtotal mode enable and disable
functions based on change in VRR mode of operation.
When Adaptive Sync Vtotal is enabled, Fixed Average Vtotal
mode is disabled and vice versa. With this commit setting
the stage for subsequent CMRR enablement.

Signed-off-by: Mitul Golani 
---
 .../drm/i915/display/intel_crtc_state_dump.c  |  4 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 24 ++--
 drivers/gpu/drm/i915/display/intel_vrr.c  | 37 +--
 3 files changed, 48 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c 
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index 2d15e82c0b3d..908a4c4ccb00 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -299,7 +299,9 @@ void intel_crtc_state_dump(const struct intel_crtc_state 
*pipe_config,
intel_dump_buffer(i915, "ELD: ", pipe_config->eld,
  drm_eld_size(pipe_config->eld));
 
-   drm_dbg_kms(>drm, "vrr: %s, vmin: %d, vmax: %d, pipeline full: 
%d, guardband: %d flipline: %d, vmin vblank: %d, vmax vblank: %d\n",
+   drm_dbg_kms(>drm,
+   "cmrr: %s, vrr: %s, vmin: %d, vmax: %d, pipeline full: %d, 
guardband: %d, flipline: %d, vmin vblank: %d, vmax vblank: %d\n",
+   str_yes_no(pipe_config->cmrr.enable),
str_yes_no(pipe_config->vrr.enable),
pipe_config->vrr.vmin, pipe_config->vrr.vmax,
pipe_config->vrr.pipeline_full, pipe_config->vrr.guardband,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f99d2de840bc..f5a69309e65a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -937,6 +937,12 @@ static bool vrr_enabling(const struct intel_crtc_state 
*old_crtc_state,
  vrr_params_changed(old_crtc_state, new_crtc_state)));
 }
 
+static bool cmrr_enabling(const struct intel_crtc_state *old_crtc_state,
+ const struct intel_crtc_state *new_crtc_state)
+{
+   return is_enabling(cmrr.enable, old_crtc_state, new_crtc_state);
+}
+
 static bool vrr_disabling(const struct intel_crtc_state *old_crtc_state,
  const struct intel_crtc_state *new_crtc_state)
 {
@@ -946,6 +952,12 @@ static bool vrr_disabling(const struct intel_crtc_state 
*old_crtc_state,
  vrr_params_changed(old_crtc_state, new_crtc_state)));
 }
 
+static bool cmrr_disabling(const struct intel_crtc_state *old_crtc_state,
+  const struct intel_crtc_state *new_crtc_state)
+{
+   return is_disabling(cmrr.enable, old_crtc_state, new_crtc_state);
+}
+
 #undef is_disabling
 #undef is_enabling
 
@@ -1064,7 +1076,8 @@ static void intel_pre_plane_update(struct 
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
enum pipe pipe = crtc->pipe;
 
-   if (vrr_disabling(old_crtc_state, new_crtc_state)) {
+   if (vrr_disabling(old_crtc_state, new_crtc_state) ||
+   cmrr_disabling(old_crtc_state, new_crtc_state)) {
intel_vrr_disable(old_crtc_state);
intel_crtc_update_active_timings(old_crtc_state, false);
}
@@ -6754,7 +6767,8 @@ static void commit_pipe_post_planes(struct 
intel_atomic_state *state,
!intel_crtc_needs_modeset(new_crtc_state))
skl_detach_scalers(new_crtc_state);
 
-   if (vrr_enabling(old_crtc_state, new_crtc_state))
+   if (vrr_enabling(old_crtc_state, new_crtc_state) ||
+   cmrr_enabling(old_crtc_state, new_crtc_state))
intel_vrr_enable(new_crtc_state);
 }
 
@@ -6851,9 +6865,11 @@ static void intel_update_crtc(struct intel_atomic_state 
*state,
 * FIXME Should be synchronized with the start of vblank somehow...
 */
if (vrr_enabling(old_crtc_state, new_crtc_state) ||
-   new_crtc_state->update_m_n || new_crtc_state->update_lrr)
+   new_crtc_state->update_m_n || new_crtc_state->update_lrr ||
+   cmrr_enabling(old_crtc_state, new_crtc_state))
intel_crtc_update_active_timings(new_crtc_state,
-new_crtc_state->vrr.enable);
+new_crtc_state->vrr.enable |
+new_crtc_state->cmrr.enable);
 
/*
 * We usually enable FIFO underrun interrupts as part of the
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 4aeccbbf1d2a..1e33661062b3 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -224,7 +224,7 @@ void intel_vrr_send_push(const struct intel_crtc_state 
*crtc_state)
struct drm_i915_private *dev_priv =

[Intel-gfx] [RFC 1/3] drm/i915: Define and compute Transcoder CMRR registers

2023-11-14 Thread Mitul Golani

Add register definitions for Transcoder Fixed Average
Vtotal mode/CMRR function, with the necessary bitfields.
Compute these registers when CMRR is enabled, extending
Adaptive refresh rate capabilities.

Signed-off-by: Mitul Golani 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 23 -
 .../drm/i915/display/intel_display_types.h|  6 +
 drivers/gpu/drm/i915/display/intel_vrr.c  | 25 ++-
 drivers/gpu/drm/i915/i915_reg.h   | 14 +++
 4 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 125903007a29..f99d2de840bc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -921,6 +921,13 @@ static bool vrr_params_changed(const struct 
intel_crtc_state *old_crtc_state,
old_crtc_state->vrr.pipeline_full != 
new_crtc_state->vrr.pipeline_full;
 }
 
+static bool cmrr_params_changed(const struct intel_crtc_state *old_crtc_state,
+   const struct intel_crtc_state *new_crtc_state)
+{
+   return old_crtc_state->cmrr.cmrr_m != new_crtc_state->cmrr.cmrr_m ||
+   old_crtc_state->cmrr.cmrr_n != new_crtc_state->cmrr.cmrr_n;
+}
+
 static bool vrr_enabling(const struct intel_crtc_state *old_crtc_state,
 const struct intel_crtc_state *new_crtc_state)
 {
@@ -5067,6 +5074,16 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
} \
 } while (0)
 
+#define PIPE_CONF_CHECK_LLI(name) do { \
+   if (current_config->name != pipe_config->name) { \
+   pipe_config_mismatch(fastset, crtc, __stringify(name), \
+"(expected %lli, found %lli)", \
+current_config->name, \
+pipe_config->name); \
+   ret = false; \
+   } \
+} while (0)
+
 #define PIPE_CONF_CHECK_BOOL(name) do { \
if (current_config->name != pipe_config->name) { \
pipe_config_mismatch(fastset, crtc,  __stringify(name), \
@@ -5447,10 +5464,13 @@ intel_pipe_config_compare(const struct intel_crtc_state 
*current_config,
PIPE_CONF_CHECK_I(vrr.flipline);
PIPE_CONF_CHECK_I(vrr.pipeline_full);
PIPE_CONF_CHECK_I(vrr.guardband);
+   PIPE_CONF_CHECK_LLI(cmrr.cmrr_m);
+   PIPE_CONF_CHECK_LLI(cmrr.cmrr_n);
}
 
 #undef PIPE_CONF_CHECK_X
 #undef PIPE_CONF_CHECK_I
+#undef PIPE_CONF_CHECK_LLI
 #undef PIPE_CONF_CHECK_BOOL
 #undef PIPE_CONF_CHECK_BOOL_INCOMPLETE
 #undef PIPE_CONF_CHECK_P
@@ -6790,7 +6810,8 @@ static void intel_pre_update_crtc(struct 
intel_atomic_state *state,
intel_crtc_needs_fastset(new_crtc_state))
icl_set_pipe_chicken(new_crtc_state);
 
-   if (vrr_params_changed(old_crtc_state, new_crtc_state))
+   if (vrr_params_changed(old_crtc_state, new_crtc_state) ||
+   cmrr_params_changed(old_crtc_state, new_crtc_state))
intel_vrr_set_transcoder_timings(new_crtc_state);
}
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9a44350ba05d..e42a0807227b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1406,6 +1406,12 @@ struct intel_crtc_state {
u16 flipline, vmin, vmax, guardband;
} vrr;
 
+   /* Content Match Refresh Rate state */
+   struct {
+   bool enable;
+   u64 cmrr_n, cmrr_m;
+   } cmrr;
+
/* Stream Splitter for eDP MSO */
struct {
bool enable;
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
b/drivers/gpu/drm/i915/display/intel_vrr.c
index 5d905f932cb4..4aeccbbf1d2a 100644
--- a/drivers/gpu/drm/i915/display/intel_vrr.c
+++ b/drivers/gpu/drm/i915/display/intel_vrr.c
@@ -199,6 +199,19 @@ void intel_vrr_set_transcoder_timings(const struct 
intel_crtc_state *crtc_state)
return;
}
 
+   if (crtc_state->cmrr.enable) {
+   intel_de_write(dev_priv, TRANS_VRR_CTL(cpu_transcoder),
+  VRR_CTL_CMRR_ENABLE | trans_vrr_ctl(crtc_state));
+   intel_de_write(dev_priv, TRANS_CMRR_M_HI(cpu_transcoder),
+  upper_32_bits(crtc_state->cmrr.cmrr_m));
+   intel_de_write(dev_priv, TRANS_CMRR_M_LO(cpu_transcoder),
+  lower_32_bits(crtc_state->cmrr.cmrr_m));
+   intel_de_write(dev_priv, TRANS_CMRR_N_HI(cpu_transcoder),
+  upper_32_bits(crtc_state->cmrr.cmrr_n));
+   intel_de_write(dev_priv, TRANS_CMRR_N_LO(cpu_transcoder),
+

[Intel-gfx] [RFC 0/3] Implement CMRR Support

2023-11-14 Thread Mitul Golani

CMRR is a display feature that uses adaptive sync
framework to vary Vtotal slightly to match the
content rate exactly without frame drops. This
feature is a variation of VRR where it varies Vtotal
slightly (between additional 0 and 1 Vtotal scanlines)
to match content rate exactly without frame drops
using the adaptive sync framework.

enable this feature by programing new registers for
CMRR enable, CMRR_M, CMRR_N, vmin=vmax=flipline.The
CMRR_M/CMRR_N ratio represents the fractional part
in (actual refresh rate/target refresh rate) * origVTotal.

Signed-off-by: Mitul Golani 

Mitul Golani (3):
  drm/i915: Define and compute Transcoder CMRR registers
  drm/i915: Add Enable/Disable for CMRR based on VRR state
  drm/i915: Compute CMRR and calculate vtotal

 .../drm/i915/display/intel_crtc_state_dump.c  |   4 +-
 drivers/gpu/drm/i915/display/intel_display.c  |  48 +-
 .../drm/i915/display/intel_display_device.h   |   1 +
 .../drm/i915/display/intel_display_types.h|   6 +
 drivers/gpu/drm/i915/display/intel_vrr.c  | 141 +++---
 drivers/gpu/drm/i915/i915_reg.h   |  14 ++
 6 files changed, 191 insertions(+), 23 deletions(-)

-- 
2.25.1

Re: [Intel-gfx] Regression on linux-next (next-20231107)

2023-11-14 Thread Borah, Chaitanya Kumar

Hello Krister,

> -Original Message-
> From: Krister Johansen 
> Sent: Tuesday, November 14, 2023 11:11 PM
> To: Borah, Chaitanya Kumar 
> Cc: Krister Johansen ; intel-
> g...@lists.freedesktop.org; Kurmi, Suresh Kumar
> ; Saarinen, Jani ;
> Miklos Szeredi 
> Subject: Re: Regression on linux-next (next-20231107)
> 
> Hi Chaitanya,
> 
> On Mon, Nov 13, 2023 at 06:21:57AM +, Borah, Chaitanya Kumar wrote:
> > Hello Krister,
> >
> > Any luck with this?
> >
> > > -Original Message-
> > > From: Borah, Chaitanya Kumar
> > > Sent: Friday, November 10, 2023 9:09 AM
> > > To: Krister Johansen 
> > > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar
> > > ; Saarinen, Jani
> > > ; Miklos Szeredi 
> > > Subject: RE: Regression on linux-next (next-20231107)
> > >
> > > Hello Krister,
> > >
> > > > -Original Message-
> > > > From: Krister Johansen 
> > > > Sent: Friday, November 10, 2023 2:10 AM
> > > > To: Borah, Chaitanya Kumar 
> > > > Cc: k...@templeofstupid.com; intel-gfx@lists.freedesktop.org;
> > > > Kurmi, Suresh Kumar ; Saarinen, Jani
> > > > ; Miklos Szeredi 
> > > > Subject: Re: Regression on linux-next (next-20231107)
> > > >
> > > > Hi Chaitanya,
> > > >
> > > > On Thu, Nov 09, 2023 at 05:00:09PM +, Borah, Chaitanya Kumar
> wrote:
> > > > > Hello Krister,
> > > > >
> > > > > Hope you are doing well. I am Chaitanya from the linux graphics
> > > > > team in
> > > > Intel.
> > > > >
> > > > > This mail is regarding a regression we are seeing in our CI
> > > > > runs[1] for some
> > > > machines (dg2 and adl-p) on linux-next  repository.
> > > > >
> > > > > Since the version next-20231107 [2], we are seeing the following
> > > > > error 
> > > > > ```
> > > > > <4>[   32.015910] stack segment:  [#1] PREEMPT SMP NOPTI
> > > > > <4>[   32.021048] CPU: 15 PID: 766 Comm: fusermount Not tainted
> 6.6.0-
> > > > next-20231107-next-20231107-g5cd631a52568+ #1
> > > > > <4>[   32.031135] Hardware name: Intel Corporation Raptor Lake Client
> > > > Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS
> > > > RPLSFWI1.R00.4221.A00.2305271351 05/27/2023
> > > > > <4>[   32.044657] RIP: 0010:fuse_evict_inode+0x61/0x150 [fuse]
> > > > > 
> > > > > 
> > > > > ``
> > > > > ```
> > > > >
> > > > > Details log can be found in [3].
> > > > >
> > > > > After bisecting the tree, the following patch [4] seems to be
> > > > > the first "bad" commit
> > > > >
> > > > >
> > > > > 
> > > > > 
> > > > > ``
> > > > > ```
> > > > > 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5 is the first bad commit
> > > > > commit 513dfacefd712bcbfab64e1a9c9c3e0d51c2dca5
> > > > > Author: Krister Johansen k...@templeofstupid.com
> > > > > Date:   Fri Nov 3 10:39:47 2023 -0700
> > > > >
> > > > > fuse: share lookup state between submount and its parent
> > > > >
> > > > > Fuse submounts do not perform a lookup for the nodeid that
> > > > > they
> > > inherit
> > > > > from their parent.  Instead, the code decrements the nlookup on 
> > > > > the
> > > > > submount's fuse_inode when it is instantiated, and no forget is
> > > > > performed when a submount root is evicted.
> > > > >
> > > > > Trouble arises when the submount's parent is evicted despite the
> > > > > submount itself being in use.  In this author's case, the submount
> was
> > > > > in a container and deatched from the initial mount namespace via a
> > > > > MNT_DEATCH operation.  When memory pressure triggered the
> > > > > shrinker,
> > > > the
> > > > > inode from the parent was evicted, which triggered enough forgets
> to
> > > > > render the submount's nodeid invalid.
> > > > >
> > > > > Since submounts should still function, even if their parent goes 
> > > > > away,
> > > > > solve this problem by sharing refcounted state between the parent
> and
> > > > > its submount.  When all of the references on this shared state 
> > > > > reach
> > > > > zero, it's safe to forget the final lookup of the fuse nodeid.
> > > > >
> > > > >
> > > > > 
> > > > > 
> > > > > ``
> > > > > ```
> > > > >
> > > > > We also verified that if we revert the patch the issue is not seen.
> > > > >
> > > > > Could you please check why the patch causes this regression and
> > > > > provide a
> > > > fix if necessary?
> > > >
> > > > Apologies for the inconvenience.  I've reproduced the problem,
> > > > tested a fix, and am in the process of preparing patches to send to
> Miklos.
> > > > I'll cc the people on this e-mail in that thread.
> > > >
> > > > > [3]
> > > > > http://gfx-ci.igk.intel.com/tree/linux-next/next-20231109/bat-dg
> > > > > 2-14
> > > > > /b
> > > > > oot0.txt
> > > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsb: DSB code refactoring (rev7)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/dsb: DSB code refactoring (rev7)
URL   : https://patchwork.freedesktop.org/series/124141/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13876 -> Patchwork_124141v7


Summary
---

  **FAILURE**

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

Participating hosts (37 -> 39)
--

  Additional (3): bat-dg2-8 bat-mtlp-8 fi-hsw-4770 
  Missing(1): fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gem_contexts:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v7/fi-hsw-4770/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_tlb:
- bat-rpls-1: [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13876/bat-rpls-1/igt@i915_selftest@live@gt_tlb.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v7/bat-rpls-1/igt@i915_selftest@live@gt_tlb.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- fi-bsw-n3050:   [FAIL][4] ([i915#8293]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13876/fi-bsw-n3050/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v7/fi-bsw-n3050/boot.html
- bat-jsl-1:  [FAIL][6] ([i915#8293]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13876/bat-jsl-1/boot.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v7/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

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

  * igt@gem_huc_copy@huc-copy:
- bat-jsl-1:  NOTRUN -> [SKIP][10] ([i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v7/bat-jsl-1/igt@gem_huc_c...@huc-copy.html

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

  * igt@gem_lmem_swapping@verify-random:
- bat-adlp-11:NOTRUN -> [SKIP][12] ([i915#4613]) +3 other tests skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v7/bat-adlp-11/igt@gem_lmem_swapp...@verify-random.html
- bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#4613]) +3 other tests skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v7/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html
- bat-jsl-1:  NOTRUN -> [SKIP][14] ([i915#4613]) +3 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v7/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html

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

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

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

  * igt@gem_tiled_pread_basic:
- bat-dg2-8:  NOTRUN -> [SKIP][20] ([i915#4079]) +1 other test skip
   [20]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dsb: DSB code refactoring (rev7)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/dsb: DSB code refactoring (rev7)
URL   : https://patchwork.freedesktop.org/series/124141/
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:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit'
+./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:238: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'

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsb: DSB code refactoring (rev7)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/dsb: DSB code refactoring (rev7)
URL   : https://patchwork.freedesktop.org/series/124141/
State : warning

== Summary ==

Error: dim checkpatch failed
73f25cc58b45 drm/i915/dsb: DSB code refactoring
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'
-:292: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#292: 
new file mode 100644

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

Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute

2023-11-14 Thread Rodrigo Vivi

On Sun, Nov 05, 2023 at 05:27:03PM +, Paz Zcharya wrote:
> Fix the value of variable `phys_base` to be the relative offset in
> stolen memory, and not the absolute offset of the GSM.

to me it looks like the other way around. phys_base is the physical
base address for the frame_buffer. Setting it to zero doesn't seem
to make that relative. And also doesn't look right.

> 
> Currently, the value of `phys_base` is set to "Surface Base Address,"
> which in the case of Meter Lake is 0xfc00_.

I don't believe this is a fixed value. IIRC this comes from the register
set by video bios, where the idea is to reuse the fb that was used so
far.

With this in mind I don't understand how that could overflow. Maybe
the size of the stolen is not right? maybe the size? maybe different
memory region?

> This causes the
> function `i915_gem_object_create_region_at` to fail in line 128, when
> it attempts to verify that the range does not overflow:
> 
> if (range_overflows(offset, size, resource_size(>region)))
>   return ERR_PTR(-EINVAL);
> 
> where:
>   offset = 0xfc00
>   size = 0x8ca000
>   mem->region.end + 1 = 0x440
>   mem->region.start = 0x80
>   resource_size(>region) = 0x3c0
> 
> call stack:
>   i915_gem_object_create_region_at
>   initial_plane_vma
>   intel_alloc_initial_plane_obj
>   intel_find_initial_plane_obj
>   intel_crtc_initial_plane_config
> 
> Looking at the flow coming next, we see that `phys_base` is only used
> once, in function `_i915_gem_object_stolen_init`, in the context of
> the offset *in* the stolen memory. Combining that with an
> examinination of the history of the file seems to indicate the
> current value set is invalid.
> 
> call stack (functions using `phys_base`)
>   _i915_gem_object_stolen_init
>   __i915_gem_object_create_region
>   i915_gem_object_create_region_at
>   initial_plane_vma
>   intel_alloc_initial_plane_obj
>   intel_find_initial_plane_obj
>   intel_crtc_initial_plane_config
> 
> [drm:_i915_gem_object_stolen_init] creating preallocated stolen
> object: stolen_offset=0x, size=0x008ca000
> 
> Signed-off-by: Paz Zcharya 
> ---
> 
>  drivers/gpu/drm/i915/display/intel_plane_initial.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
> b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> index a55c09cbd0e4..e696cb13756a 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
> @@ -90,7 +90,7 @@ initial_plane_vma(struct drm_i915_private *i915,
>   "Using phys_base=%pa, based on initial plane 
> programming\n",
>   _base);
>   } else {
> - phys_base = base;
> + phys_base = 0;
>   mem = i915->mm.stolen_region;
>   }
>  
> -- 
> 2.42.0.869.gea05f2083d-goog
>

[Intel-gfx] ✓ Fi.CI.BAT: success for Selftest for FAST_REQUEST feature (rev3)

2023-11-14 Thread Patchwork

== Series Details ==

Series: Selftest for FAST_REQUEST feature (rev3)
URL   : https://patchwork.freedesktop.org/series/126044/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_126044v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 39)
--

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

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/bat-jsl-1/boot.html

  
 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-hsw-4770/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hugepages:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][5] ([i915#9527])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/fi-hsw-4770/igt@i915_selftest@l...@hugepages.html

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

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#5190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271]) +12 other tests 
skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#1836])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  * igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][10] ([fdo#109271]) +29 other tests 
skip
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/fi-pnv-d510/igt@kms_psr@primary_page_flip.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_126044v3/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][12] ([i915#9174]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html

  * igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[DMESG-FAIL][14] ([i915#6868]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html

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

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][18] ([i915#8668]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126044v3/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#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#5190]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Selftest for FAST_REQUEST feature (rev3)

2023-11-14 Thread Patchwork

== Series Details ==

Series: Selftest for FAST_REQUEST feature (rev3)
URL   : https://patchwork.freedesktop.org/series/126044/
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.BAT: success for drm/i915: do not clean GT table on error path (rev2)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915: do not clean GT table on error path (rev2)
URL   : https://patchwork.freedesktop.org/series/126385/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_126385v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 40)
--

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

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v2/fi-bsw-n3050/boot.html

  
 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-hsw-4770/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v2/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@i915_selftest@live@hangcheck:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][10] ([i915#9527])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v2/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html

  * igt@i915_selftest@live@requests:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][11] ([i915#9527])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v2/fi-hsw-4770/igt@i915_selftest@l...@requests.html

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

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

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][15] ([fdo#109271]) +12 other tests 
skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v2/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][16] ([i915#1836])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v2/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

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

  * igt@kms_psr@sprite_plane_onoff:
- bat-jsl-3:  [PASS][18] -> [SKIP][19] ([i915#9648]) +3 other tests 
skip
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-3/igt@kms_psr@sprite_plane_onoff.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v2/bat-jsl-3/igt@kms_psr@sprite_plane_onoff.html
- fi-hsw-4770:NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#1072]) +3 
other tests skip
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v2/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][21] ([i915#9174]) -> [PASS][22]
   [21]:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: do not clean GT table on error path (rev2)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915: do not clean GT table on error path (rev2)
URL   : https://patchwork.freedesktop.org/series/126385/
State : warning

== Summary ==

Error: dim checkpatch failed
0e75a4af93e7 drm/i915: do not clean GT table on error path
-:14: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line 
(possible unwrapped commit description?)
#14: 
BUG i915_request (...): Objects remaining in i915_request on 
__kmem_cache_shutdown()

-:27: WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12 chars 
of sha1> ("")' - ie: 'Fixes: bec68cc9ea42 ("drm/i915: Prepare for 
multiple GTs")'
#27: 
Fixes: bec68cc9ea42d8 ("drm/i915: Prepare for multiple GTs")

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v1,1/1] drm/i915/gt: Dont wait forever when idling in suspend

2023-11-14 Thread Patchwork

== Series Details ==

Series: series starting with [v1,1/1] drm/i915/gt: Dont wait forever when 
idling in suspend
URL   : https://patchwork.freedesktop.org/series/126414/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_126414v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 38)
--

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

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- fi-bsw-n3050:   [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-bsw-n3050/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126414v1/fi-bsw-n3050/boot.html
- bat-adlp-11:[PASS][3] -> [FAIL][4] ([i915#8293])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-adlp-11/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126414v1/bat-adlp-11/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries:
- bat-jsl-3:  [PASS][5] -> [INCOMPLETE][6] ([i915#9668])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-3/igt@debugfs_test@read_all_entries.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126414v1/bat-jsl-3/igt@debugfs_test@read_all_entries.html

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

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

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

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][12] ([i915#1836])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126414v1/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

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

  * igt@kms_psr@sprite_plane_onoff:
- bat-jsl-1:  [PASS][14] -> [SKIP][15] ([i915#9648]) +2 other tests 
skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-1/igt@kms_psr@sprite_plane_onoff.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126414v1/bat-jsl-1/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][16] ([i915#9174]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126414v1/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][18] ([i915#5334]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126414v1/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).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
  [i915#7392]: https://gitlab.freedesktop.org/drm/intel/issues/7392
  [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
  [i915#8747]: https://gitlab.freedesktop.org/drm/intel/issues/8747
  [i915#9174]: https://gitlab.freedesktop.org/drm/intel/issues/9174
  [i915#9648]: https://gitlab.freedesktop.org/drm/intel/issues/9648
  [i915#9668]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v1,1/1] drm/i915/gt: Dont wait forever when idling in suspend

2023-11-14 Thread Patchwork

== Series Details ==

Series: series starting with [v1,1/1] drm/i915/gt: Dont wait forever when 
idling in suspend
URL   : https://patchwork.freedesktop.org/series/126414/
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.BAT: failure for drm/i915/display: keep struct intel_display members sorted

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/display: keep struct intel_display members sorted
URL   : https://patchwork.freedesktop.org/series/126413/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_126413v1


Summary
---

  **FAILURE**

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

Participating hosts (39 -> 28)
--

  Missing(11): fi-skl-guc bat-adlm-1 fi-tgl-1115g4 fi-cfl-8700k fi-apl-guc 
fi-snb-2520m fi-glk-j4005 fi-elk-e7500 fi-blb-e6850 bat-jsl-3 bat-jsl-1 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@migrate:
- bat-rpls-1: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-rpls-1/igt@i915_selftest@l...@migrate.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/bat-rpls-1/igt@i915_selftest@l...@migrate.html

  * igt@kms_pipe_crc_basic@hang-read-crc@pipe-c-vga-1:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/fi-hsw-4770/igt@kms_pipe_crc_basic@hang-read-...@pipe-c-vga-1.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][4] ([i915#8293]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-hsw-4770/boot.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

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

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

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#5190])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_flip@basic-flip-vs-dpms@d-dp5:
- bat-adlp-11:[PASS][10] -> [DMESG-FAIL][11] ([i915#6868])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-adlp-11/igt@kms_flip@basic-flip-vs-d...@d-dp5.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-d...@d-dp5.html

  * igt@kms_flip@basic-flip-vs-modeset:
- bat-adlp-11:NOTRUN -> [SKIP][12] ([i915#3637])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/bat-adlp-11/igt@kms_f...@basic-flip-vs-modeset.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][13] ([fdo#109271]) +7 other tests 
skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][14] ([i915#1836])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][15] ([i915#9174]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126413v1/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6868]: https://gitlab.freedesktop.org/drm/intel/issues/6868
  [i915#8293]:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: keep struct intel_display members sorted

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/display: keep struct intel_display members sorted
URL   : https://patchwork.freedesktop.org/series/126413/
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] linux-next: Signed-off-by missing for commit in the drm-misc tree

2023-11-14 Thread Luben Tuikov

On 2023-11-13 22:08, Stephen Rothwell wrote:
> Hi Luben,
> 
> BTW, cherry picking commits does not avoid conflicts - in fact it can
> cause conflicts if there are further changes to the files affected by
> the cherry picked commit in either the tree/branch the commit was
> cheery picked from or the destination tree/branch (I have to deal with
> these all the time when merging the drm trees in linux-next).  Much
> better is to cross merge the branches so that the patch only appears
> once or have a shared branches that are merged by any other branch that
> needs the changes.
> 
> I understand that things are not done like this in the drm trees :-(

Hi Stephen,

Thank you for the clarification--understood. I'll be more careful in the future.
Thanks again! :-)
-- 
Regards,
Luben


OpenPGP_0x4C15479431A334AF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[Intel-gfx] ✓ Fi.CI.BAT: success for Resolve suspend-resume racing with GuC destroy-context-worker (rev6)

2023-11-14 Thread Patchwork

== Series Details ==

Series: Resolve suspend-resume racing with GuC destroy-context-worker (rev6)
URL   : https://patchwork.freedesktop.org/series/121916/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_121916v6


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 36)
--

  Additional (1): fi-pnv-d510 
  Missing(4): fi-hsw-4770 bat-mtlp-8 fi-snb-2520m bat-dg1-5 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_suspend@basic-s3-without-i915:
- bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#6645])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v6/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html
- bat-rpls-1: [PASS][2] -> [ABORT][3] ([i915#7978] / [i915#9631])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v6/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#1836])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v6/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][6] ([i915#9174]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v6/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html

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

  * igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[DMESG-FAIL][10] ([i915#6868]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v6/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.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_13875/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_121916v6/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html

  * igt@kms_psr@primary_mmap_gtt:
- bat-jsl-1:  [SKIP][14] ([i915#9648]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-1/igt@kms_psr@primary_mmap_gtt.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v6/bat-jsl-1/igt@kms_psr@primary_mmap_gtt.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#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
  [i915#6868]: https://gitlab.freedesktop.org/drm/intel/issues/6868
  [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#9174]: https://gitlab.freedesktop.org/drm/intel/issues/9174
  [i915#9631]: https://gitlab.freedesktop.org/drm/intel/issues/9631
  [i915#9648]: https://gitlab.freedesktop.org/drm/intel/issues/9648


Build changes
-

  * Linux: CI_DRM_13875 -> Patchwork_121916v6

  CI-20190529: 20190529
  CI_DRM_13875: 00536be456cfe5f687c0e782f8dfba7db666d89b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_7588: 328c5873b8f061267fdf86ed32cb5ecc611ba081 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_121916v6: 00536be456cfe5f687c0e782f8dfba7db666d89b @ 
git://anongit.freedesktop.org/gfx-ci/linux


### Linux commits

d8df17a0efee drm/i915/guc: Close deregister-context race against CT-loss
9acb9d003c2b drm/i915/guc: Flush context

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Resolve suspend-resume racing with GuC destroy-context-worker (rev6)

2023-11-14 Thread Patchwork

== Series Details ==

Series: Resolve suspend-resume racing with GuC destroy-context-worker (rev6)
URL   : https://patchwork.freedesktop.org/series/121916/
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.BAT: success for drm/edid/firmware: drop drm_kms_helper.edid_firmware backward compat (rev2)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/edid/firmware: drop drm_kms_helper.edid_firmware backward compat 
(rev2)
URL   : https://patchwork.freedesktop.org/series/124065/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_124065v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 37)
--

  Additional (1): fi-pnv-d510 
  Missing(3): bat-mtlp-8 bat-kbl-2 fi-snb-2520m 

Known issues


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

### CI changes ###

 Possible fixes 

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

  

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@requests:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][3] ([i915#9527])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124065v2/fi-hsw-4770/igt@i915_selftest@l...@requests.html

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

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271]) +12 other tests 
skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124065v2/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#1836])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124065v2/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

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

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

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][10] ([i915#9174]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124065v2/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html

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

  * igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[DMESG-FAIL][14] ([i915#6868]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124065v2/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html

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

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

  * igt@kms_psr@primary_mmap_gtt:
- bat-jsl-1:  [SKIP][20] ([i915#9648]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-1/igt@kms_psr@primary_mmap_gtt.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124065v2/bat-jsl-1/igt@kms_psr@primary_mmap_gtt.html

  
  {name}: This element is

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid/firmware: drop drm_kms_helper.edid_firmware backward compat (rev2)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/edid/firmware: drop drm_kms_helper.edid_firmware backward compat 
(rev2)
URL   : https://patchwork.freedesktop.org/series/124065/
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.BAT: failure for drm/i915: Also check for VGA converter in eDP probe

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915: Also check for VGA converter in eDP probe
URL   : https://patchwork.freedesktop.org/series/126404/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_126404v1


Summary
---

  **FAILURE**

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

Participating hosts (39 -> 37)
--

  Additional (1): fi-kbl-soraka 
  Missing(3): fi-skl-guc bat-kbl-2 fi-snb-2520m 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@dmabuf:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126404v1/fi-hsw-4770/igt@i915_selftest@l...@dmabuf.html

  * igt@i915_selftest@live@gt_pm:
- bat-rpls-1: [PASS][2] -> [INCOMPLETE][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-rpls-1/igt@i915_selftest@live@gt_pm.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126404v1/bat-rpls-1/igt@i915_selftest@live@gt_pm.html

  * igt@kms_addfb_basic@bad-pitch-32:
- fi-kbl-soraka:  NOTRUN -> [INCOMPLETE][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126404v1/fi-kbl-soraka/igt@kms_addfb_ba...@bad-pitch-32.html

  
Known issues


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

### CI changes ###

 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][5] ([i915#8293]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-hsw-4770/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126404v1/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

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

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

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

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

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#5190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126404v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][13] ([fdo#109271]) +12 other tests 
skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126404v1/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

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

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

  * igt@kms_psr@sprite_plane_onoff:
- bat-jsl-1:  [PASS][16] -> [SKIP][17] ([i915#9648]) +2 other tests 
skip
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-1/igt@kms_psr@sprite_plane_onoff.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126404v1/bat-jsl-1/igt@kms_psr@sprite_plane_onoff.html
- fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#1072]) +3 
other tests skip
   [18]:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix fractional bpp handling in intel_link_bw_reduce_bpp()

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915: Fix fractional bpp handling in intel_link_bw_reduce_bpp()
URL   : https://patchwork.freedesktop.org/series/126403/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_126403v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 38)
--

  Additional (1): fi-pnv-d510 
  Missing(2): fi-snb-2520m bat-dg1-5 

Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][1] -> [FAIL][2] ([i915#8293])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-1/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/bat-jsl-1/boot.html

  
 Possible fixes 

  * boot:
- fi-hsw-4770:[FAIL][3] ([i915#8293]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-hsw-4770/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/fi-hsw-4770/boot.html

  

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#7978])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html

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

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][9] ([i915#9527])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

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

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#5190])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_busy@basic@modeset:
- bat-adlp-11:[PASS][12] -> [DMESG-FAIL][13] ([i915#6868])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-adlp-11/igt@kms_busy@ba...@modeset.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/bat-adlp-11/igt@kms_busy@ba...@modeset.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][14] ([fdo#109271]) +12 other tests 
skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@nonblocking-crc:
- bat-dg2-11: NOTRUN -> [SKIP][15] ([i915#1845] / [i915#9197])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc.html

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][16] ([i915#1836])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

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

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

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][19] ([i915#9174]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126403v1/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Remove dead code around intel_atomic_helper->free_list (rev4)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/display: Remove dead code around 
intel_atomic_helper->free_list (rev4)
URL   : https://patchwork.freedesktop.org/series/126250/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_126250v4


Summary
---

  **FAILURE**

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

Participating hosts (39 -> 39)
--

  Additional (2): fi-kbl-soraka 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_126250v4:

### 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_126250v4/fi-kbl-soraka/igt@i915_selftest@l...@perf.html

  
Known issues


  Here are the changes found in Patchwork_126250v4 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_13875/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126250v4/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-cfl-8109u:   [PASS][4] -> [ABORT][5] ([i915#8213])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-cfl-8109u/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126250v4/fi-cfl-8109u/igt@gem_exec_suspend@basic...@smem.html

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

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

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

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

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

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

  * igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-atsm-1: NOTRUN -> [SKIP][12] ([i915#1836])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126250v4/bat-atsm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html

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

  
 Possible fixes 

  * igt@i915_selftest@live@gem_contexts:
- bat-atsm-1: [INCOMPLETE][14] ([i915#9174]) -> [PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126250v4/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html

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

  * igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[DMESG-FAIL][18] ([i915#6868]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html

Re: [Intel-gfx] [PATCH] drm/i915/gsc: Assign a uabi class number to the GSC CS

2023-11-14 Thread Daniele Ceraolo Spurio





On 11/14/2023 9:20 AM, Tvrtko Ursulin wrote:


On 14/11/2023 17:03, Daniele Ceraolo Spurio wrote:

On 11/13/2023 8:46 AM, Tvrtko Ursulin wrote:

On 13/11/2023 15:51, Daniele Ceraolo Spurio wrote:

On 11/10/2023 4:00 AM, Tvrtko Ursulin wrote:


On 09/11/2023 23:53, Daniele Ceraolo Spurio wrote:
The GSC CS is not exposed to the user, so we skipped assigning a 
uabi

class number for it. However, the trace logs use the uabi class and
instance to identify the engine, so leaving uabi class unset 
makes the

GSC CS show up as the RCS in those logs.
Given that the engine is not exposed to the user, we can't add a new
case in the uabi enum, so we insted internally define a kernel
reserved class using the next free number.

Fixes: 194babe26bdc ("drm/i915/mtl: don't expose GSC command 
streamer to the user")
Signed-off-by: Daniele Ceraolo Spurio 


Cc: Tvrtko Ursulin 
Cc: Alan Previn 
Cc: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_engine_user.c | 17 -
  drivers/gpu/drm/i915/gt/intel_engine_user.h |  4 
  drivers/gpu/drm/i915/i915_drm_client.h  |  2 +-
  drivers/gpu/drm/i915/i915_drv.h |  2 +-
  4 files changed, 14 insertions(+), 11 deletions(-)

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

index 118164ddbb2e..3fd32bedd6e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -47,6 +47,7 @@ static const u8 uabi_classes[] = {
  [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
  [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
  [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
+    [OTHER_CLASS] = I915_KERNEL_RSVD_CLASS,


Could we set it to -1 (aka no uabi class) to avoid needing to 
maintain the new macros?


And then just teach intel_engines_driver_register to skip -1. 
Would also need teaching engine_rename to handle -1.


Might end up a smaller and more maintainable patch - worth a try 
do you think?


That was my initial idea as well, but the issue with this approach 
is the engine_uabi_class_count[] array, which is sized based on the 
number of uabi classes, so having class -1 would needlessly 
increase its size a lot even when using a u8. I thought about 
limiting the class entry to 3 


I was thinking the -1 entry wouldn't be in that array since -1 is 
not uabi class by its very definition. It is not reachable from the 
outside so no need to be there.


The issue there is that the array is used to assign uabi_instance, 
but I can hardcode that to 0 for now since we don't expect any new 
engines of that class. would that work for you?


My issue is that the starting position here is GSC engine has no uabi 
class, therefore it shouldn't have an uabi instance either, therefore 
the fact you cannot use the array called engine_*uabi*_class_count to 
assign it something which it shouldn't have, shouldn't be an argument. ;)


Agreed. The problem is that we use the uabi_class/instance for things 
that aren't strictly uabi (i.e. the traces) so we need to assign a value 
to those even if we don't need it for actual uabi purposes.





Otherwise I'll try the 3-bits thing and see how that looks.


3-bits.. I have to admit I don't know what you mean by that?


I was referring to limiting the uabi class index to 3 bits to limit the 
max array size to 8 and use -1 for the GSC uabi_class.




I can try to sketch out tomorrow what I have in mind. Lets go from 
there. I might fail and concede there is nothing to be gained by using 
a different approach.


sounds good.

Thanks,
Daniele



Regards,

Tvrtko



Daniele



bits so the array would max out at 8 entries, but that seemed to be 
getting a bit too convoluted. I can give it a go if you think it's 
be cleaner overall.


I had a feeling it would be, but without trying it out I won't claim 
100%.


Note that this patch does not introduce any new macros that would 
need to be maintained. I915_LAST_UABI_ENGINE_CLASS already existed 
(I just moved it from one file to another) and is the only one that 
changes when a new "real" uabi class is added; the other defines 
are based on this one. This also implies that if a new uabi class 
is added then I915_KERNEL_RSVD_CLASS would be bumped to the next 
free number, which would cause the GSC to show as a different uabi 
class in newer logs; considering that i915 is on its way out, a new 
class seems very unlikely so I thought it'd be an acceptable 
compromise to keep things simple.





  };
    static int engine_cmp(void *priv, const struct list_head *A,
@@ -138,7 +139,7 @@ const char *intel_engine_class_repr(u8 class)
  [COPY_ENGINE_CLASS] = "bcs",
  [VIDEO_DECODE_CLASS] = "vcs",
  [VIDEO_ENHANCEMENT_CLASS] = "vecs",
-    [OTHER_CLASS] = "other",
+    [OTHER_CLASS] = "gsc",


Maybe unrelated?


no. Before this patch, we hardcoded "gsc" below when calling 
engine_rename() for it. With this patch, we use the name from this

Re: [Intel-gfx] [PATCH v1 1/1] drm/i915/gt: Dont wait forever when idling in suspend

2023-11-14 Thread Teres Alexis, Alan Previn

On Tue, 2023-11-14 at 08:22 -0800, Teres Alexis, Alan Previn wrote:
> When suspending, add a timeout when calling
> intel_gt_pm_wait_for_idle else if we have a leaked
> wakeref (which would be indicative of a bug elsewhere
> in the driver), driver will at exit the suspend-resume
> cycle, after the kernel detects the held reference and
> prints a message to abort suspending instead of hanging
> in the kernel forever which then requires serial connection
> or ramoops dump to debug further.
NOTE: this patch originates from Patch#3 of this other series
https://patchwork.freedesktop.org/series/121916/ (rev 5 and prior)
and was decided to be moved out as its own patch since this
patch is trying to improve general debuggability as opposed
to resolving that bug being resolved in above series.
alan:snip

> +int intel_wakeref_wait_for_idle(struct intel_wakeref *wf, int timeout_ms)
>  {
> - int err;
> + int err = 0;
>  
>   might_sleep();
>  
> - err = wait_var_event_killable(>wakeref,
> -   !intel_wakeref_is_active(wf));
> + if (!timeout_ms)
> + err = wait_var_event_killable(>wakeref,
> +   !intel_wakeref_is_active(wf));
> + else if (wait_var_event_timeout(>wakeref,
> + !intel_wakeref_is_active(wf),
> + msecs_to_jiffies(timeout_ms)) < 1)
> + err = -ETIMEDOUT;
> +
alan: paraphrasing feedback from Tvrtko on the originating series this patch:
it would be good idea to add error-injection into this timeout to ensure
we dont have any other subsytem that could inadvertently leak an rpm
wakeref (and catch such bugs in future pre-merge).

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Remove dead code around intel_atomic_helper->free_list (rev4)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/display: Remove dead code around 
intel_atomic_helper->free_list (rev4)
URL   : https://patchwork.freedesktop.org/series/126250/
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.BAT: success for series starting with [v2,1/3] drm/i915: move *_crtc_clock_get() to intel_dpll.c

2023-11-14 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: move *_crtc_clock_get() to 
intel_dpll.c
URL   : https://patchwork.freedesktop.org/series/126388/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13875 -> Patchwork_126388v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 39)
--

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

Known issues


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

### CI changes ###

 Possible fixes 

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

  

### IGT changes ###

 Issues hit 

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

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

  * igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka:  NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][6] ([i915#9642])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/fi-hsw-4770/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@slpc:
- fi-kbl-soraka:  NOTRUN -> [ABORT][7] ([i915#9663])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/fi-kbl-soraka/igt@i915_selftest@l...@slpc.html

  * igt@i915_selftest@live@workarounds:
- bat-dg1-5:  [PASS][8] -> [ABORT][9] ([i915#9413])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-dg1-5/igt@i915_selftest@l...@workarounds.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/bat-dg1-5/igt@i915_selftest@l...@workarounds.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#5190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271]) +12 other tests 
skip
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_psr@sprite_plane_onoff:
- bat-jsl-3:  [PASS][13] -> [SKIP][14] ([i915#9648]) +3 other tests 
skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-jsl-3/igt@kms_psr@sprite_plane_onoff.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/bat-jsl-3/igt@kms_psr@sprite_plane_onoff.html
- fi-hsw-4770:NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1072]) +3 
other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

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

  * igt@kms_flip@basic-flip-vs-modeset@d-dp5:
- bat-adlp-11:[DMESG-FAIL][18] ([i915#6868]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/bat-adlp-11/igt@kms_flip@basic-flip-vs-mode...@d-dp5.html

  * igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][20] ([IGT#3]) -> [PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13875/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126388v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][22]

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: move *_crtc_clock_get() to intel_dpll.c

2023-11-14 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: move *_crtc_clock_get() to 
intel_dpll.c
URL   : https://patchwork.freedesktop.org/series/126388/
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:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/3] drm/i915: move *_crtc_clock_get() to intel_dpll.c

2023-11-14 Thread Patchwork

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: move *_crtc_clock_get() to 
intel_dpll.c
URL   : https://patchwork.freedesktop.org/series/126388/
State : warning

== Summary ==

Error: dim checkpatch failed
9458caf8991c drm/i915: move *_crtc_clock_get() to intel_dpll.c
-:346: CHECK:BRACES: braces {} should be used on all arms of this statement
#346: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:458:
+   if (dpll & PLL_P1_DIVIDE_BY_TWO)
[...]
+   else {
[...]

-:348: CHECK:BRACES: Unbalanced braces around else statement
#348: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:460:
+   else {

total: 0 errors, 0 warnings, 2 checks, 424 lines checked
b86d3ea21a42 drm/i915: add vlv_pipe_to_phy() helper to replace DPIO_PHY()
-:57: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#57: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.h:120:
 }
+static inline enum dpio_phy vlv_pipe_to_phy(enum pipe pipe)

total: 0 errors, 0 warnings, 1 checks, 71 lines checked
7c7513045fb8 drm/i915: convert vlv_dpio_read()/write() from pipe to phy
-:362: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#362: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.c:953:
+   vlv_dpio_write(dev_priv, phy, CHV_TX_DW14(ch, i),
data << DPIO_UPAR_SHIFT);

-:437: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#437: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.c:1062:
+   vlv_dpio_write(dev_priv, phy, VLV_TX_DW2(port),
 uniqtranscale_reg_value);

-:466: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#466: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.c:1088:
+   vlv_dpio_write(dev_priv, phy, VLV_PCS_DW0(port),
 DPIO_PCS_TX_LANE2_RESET |

-:470: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#470: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.c:1091:
+   vlv_dpio_write(dev_priv, phy, VLV_PCS_DW1(port),
 DPIO_PCS_CLK_CRI_RXEB_EIOS_EN |

-:668: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#668: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1899:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW10(pipe),
 0x009f0003);

-:672: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#672: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1902:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW10(pipe),
 0x00df);

-:679: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#679: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1908:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW5(pipe),
 0x0df4);

-:683: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#683: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1911:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW5(pipe),
 0x0df7);

-:689: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#689: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1916:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW5(pipe),
 0x0df7);

-:693: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#693: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1919:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW5(pipe),
 0x0df4);

-:723: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#723: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1997:
+   vlv_dpio_write(dev_priv, phy, CHV_CMN_DW13(port),
5 << DPIO_CHV_S1_DIV_SHIFT |

-:735: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#735: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:2007:
+   vlv_dpio_write(dev_priv, phy, CHV_PLL_DW1(port),
DPIO_CHV_M1_DIV_BY_2 |

-:783: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#783: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:2062:
+   vlv_dpio_write(dev_priv, phy, CHV_CMN_DW14(port),
+   vlv_dpio_read(dev_priv, phy, CHV_CMN_DW14(port)) |

total: 0 errors, 0 warnings, 13 checks, 805 lines checked

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

2023-11-14 Thread Teres Alexis, Alan Previn

On Tue, 2023-11-14 at 17:52 +, Tvrtko Ursulin wrote:
> On 14/11/2023 17:37, Teres Alexis, Alan Previn wrote:
> > On Tue, 2023-11-14 at 17:27 +, Tvrtko Ursulin wrote:
> > > On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:
> > > > On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:
> > > > > On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:
> > > > > > On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
> > > > > > > On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
> 
alan:snip

> > alan: So i did trace back the gt->wakeref before i posted these patches and
> > see that within these runtime get/put calls, i believe the first 'get' leads
> > to __intel_wakeref_get_first which calls intel_runtime_pm_get via rpm_get
> > helper and eventually executes a pm_runtime_get_sync(rpm->kdev); (hanging 
> > off
> > i915_device). (naturally there is a corresponding mirros for the 
> > '_put_last').
> > So this means the first-get and last-put lets the kernel know. Thats why 
> > when
> > i tested this patch, it did actually cause the suspend to abort from kernel 
> > side
> > and the kernel would print a message indicating i915 was the one that didnt
> > release all refs.
> 
> Ah that would be much better then.
> 
> Do you know if everything gets resumed/restored correctly in that case 
> or we would need some additional work to maybe early exit from callers 
> of wait_for_suspend()?
alan: So assuming we are still discussing about a "potentially new
future leaked-wakeref bug" (i.e. putting aside the fact that
Patch #1 + #2 resolves this specific series' bug), based on the
previous testing we did, after this timeout-bail trigger,
the suspend flow bails and gt/guc operation does actually continue
as normal. However, its been a long time since we tested this so
i am not sure of how accidental-new-future bugs might play to this
assumption especially if some other subsystem that leaked the rpm
wakref but that subsystem did NOT get reset like how GuC is reset
at the end of suspend.

> 
> What I would also ask is to see if something like injecting a probing 
> failure is feasible, so we can have this new timeout exit path 
> constantly/regularly tested in CI.
alan: Thats a good idea. In line with this, i would like to point out that
rev6 of this series has been posted but i removed this Patch #3. However i did
post this Patch #3 as a standalone patch here: 
https://patchwork.freedesktop.org/series/126414/
as i anticipate this patch will truly help with future issue debuggability.

That said, i shall post a review on that patch with your suggestion to add
an injected probe error for the suspend-resume flow and follow up on that one
separately.

> 
> Regards,
> 
> Tvrtko
> 
> > alan: Anyways, i have pulled this patch out of rev6 of this series and 
> > created a
> > separate standalone patch for this patch #3 that we review independently.
> >

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

2023-11-14 Thread Teres Alexis, Alan Previn

On Tue, 2023-11-14 at 12:36 -0500, Vivi, Rodrigo wrote:
> On Tue, Nov 14, 2023 at 05:27:18PM +, Tvrtko Ursulin wrote:
> > 
> > On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:
> > > On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:
> > > > On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:
> > > > > On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
> > > > > > On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
> 
> That's a good point.
> Well, current code is already bad and buggy on suspend-resume. We could get
> suspend stuck forever without any clue of what happened.
> At least the proposed patch add some gt_warn. But, yes, the right thing
> to do should be entirely abort the suspend in case of timeout, besides the
> gt_warn.
alan: yes - thats was the whole idea for Patch #3. Only after putting such
code did we have much better debuggability on real world production platforms
+ config that may not have serial-port or ramoops-dump by default.

Btw, as per previous comments by Tvrtko - which i agreed with, I have
moved this one single patch into a separate patch on its own.
See here: https://patchwork.freedesktop.org/series/126414/
(I also maintained the RB from you Rodrigo because the patch did not changed).
And yes, the gt_warn is still in place :)

Re: [Intel-gfx] [char-misc-next 3/4] mei: pxp: re-enable client on errors

2023-11-14 Thread Winkler, Tomas



> -Original Message-
> From: Teres Alexis, Alan Previn 
> Sent: Tuesday, November 14, 2023 5:32 PM
> To: ville.syrj...@linux.intel.com; Winkler, Tomas 
> Cc: gre...@linuxfoundation.org; Usyskin, Alexander
> ; linux-ker...@vger.kernel.org; intel-
> g...@lists.freedesktop.org; Lubart, Vitaly 
> Subject: Re: [char-misc-next 3/4] mei: pxp: re-enable client on errors
> 
> On Tue, 2023-11-14 at 16:00 +0200, Ville Syrjälä wrote:
> > On Wed, Oct 11, 2023 at 02:01:56PM +0300, Tomas Winkler wrote:
> > > From: Alexander Usyskin 
> > >
> > > Disable and enable mei-pxp client on errors to clean the internal state.
> >
> > This broke i915 on my Alderlake-P laptop.

This fix was already posted, just missed the merging window
https://lkml.org/lkml/2023/10/31/636

Greg can you please take this fix into v6.7-rc2 run, or I can repost it with 
the correct subject.
Thanks
Tomas


> >
> 
> 
> Hi Alex, i just relooked at the series that got merged, and i noticed that in 
> patch
> #3 of the series, you had changed mei_pxp_send_message to return bytes sent
> instead of zero on success. IIRC, we had agreed to not effect the behavior of
> this component interface (other than adding the timeout) - this was the
> intention of Patch #4 that i was pushing for in order to spec the interface
> (which continues to say zero on success). We should fix this to stay with the
> original behavior - where mei-pxp should NOT send partial packets and will
> only return zero in success case where success is sending of the complete
> packets - so we don't need to get back the "bytes sent"
> from mei_pxp_send_message. So i think this might be causing the problem.
> 
> 
> Side note  to Ville:, are you enabling PXP kernel config by default in all 
> MESA
> contexts? I recall that MESA folks were running some CI testing with enable
> pxp contexts, but didn't realize this is being enabled by default in all 
> contexts.
> Please be aware that enabling pxp-contexts would temporarily disabled
> runtime-pm during that contexts lifetime.
> Also pxp contexts will be forced to be irrecoverable if it ever hangs.
> The former is a hardware architecture requirement but doesn't do anything if
> you're enabling display (which I beleive also blocks in ADL). The latter was a
> requirement to comply with Vulkan.
> 
> ...alan
>

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: do not clean GT table on error path

2023-11-14 Thread Andrzej Hajda




On 14.11.2023 17:30, Patchwork wrote:

Project List - Patchwork *Patch Details*
*Series:*   drm/i915: do not clean GT table on error path
*URL:*  https://patchwork.freedesktop.org/series/126385/
*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v1/index.html



  CI Bug Log - changes from CI_DRM_13873 -> Patchwork_126385v1


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_126385v1 absolutely need 
to be

verified manually.

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



Participating hosts (37 -> 39)

Additional (4): fi-kbl-soraka bat-rpls-1 bat-kbl-2 bat-dg2-9
Missing (2): fi-snb-2520m fi-pnv-d510


Possible new issues

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



  IGT changes


Possible regressions

 *

igt@i915_selftest@live@workarounds:

  o bat-adlp-9: PASS


-> INCOMPLETE





Known error [1].

[1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13844/bat-rpls-1/igt@i915_selftest@l...@workarounds.html



 *
 *

igt@i915_suspend@basic-s2idle-without-i915:

  o bat-atsm-1: PASS


-> WARN





Known issue [2].

@BUG filing, please update the filters.


[2]: https://gitlab.freedesktop.org/drm/intel/-/issues/8715

Regards
Andrzej


 *


Known issues

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



  CI changes


Issues hit

  * boot:
  o bat-jsl-1: PASS


-> FAIL


(i915#8293 )


  IGT changes


Issues hit

 *

igt@debugfs_test@basic-hwmon:

  o bat-rpls-1: NOTRUN -> SKIP


(i915#9318 )
 *

igt@fbdev@info:

 o

bat-rpls-1: NOTRUN -> SKIP


(i915#1849
 /
i915#2582 )

 o

bat-kbl-2: NOTRUN -> SKIP


(fdo#109271
 /
i915#1849 )

 *

igt@fbdev@write:

  o bat-rpls-1: NOTRUN -> SKIP


(i915#2582
) +3
other tests skip
 *

igt@gem_huc_copy@huc-copy:

  o fi-kbl-soraka: NOTRUN -> SKIP


(fdo#109271
 /
i915#2190 )
 *

igt@gem_lmem_swapping@basic:

  o fi-kbl-soraka: NOTRUN -> SKIP


(fdo#109271
 /
i915#4613
) +3
other tests skip
 *

igt@gem_lmem_swapping@parallel-random-engines:

  o bat-kbl-2: NOTRUN -> SKIP


(fdo#109271
) +24
other tests skip
 *

igt@gem_lmem_swapping@random-engines:

  o bat-rpls-1: NOTRUN -> SKIP

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

2023-11-14 Thread Tvrtko Ursulin




On 14/11/2023 17:37, Teres Alexis, Alan Previn wrote:

On Tue, 2023-11-14 at 17:27 +, Tvrtko Ursulin wrote:

On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:

On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:

On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:

On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:

On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:

alan: snip



alan: I won't say its NOT fixing anything - i am saying it's not fixing
this specific bug where we have the outstanding G2H from a context destruction
operation that got dropped. I am okay with dropping this patch in the next rev
but shall post a separate stand alone version of Patch3 - because I believe
all other i915 subsystems that take runtime-pm's DO NOT wait forever when 
entering
suspend - but GT is doing this. This means if there ever was a bug introduced,
it would require serial port or ramoops collection to debug. So i think such a
patch, despite not fixing this specific bug will be very helpful for 
debuggability
of future issues. After all, its better to fail our suspend when we have a bug
rather than to hang the kernel forever.


Issue I have is that I am not seeing how it fails the suspend when
nothing is passed out from *void* wait_suspend(gt). To me it looks the
suspend just carries on. And if so, it sounds dangerous to allow it to
do that with any future/unknown bugs in the suspend sequence. Existing
timeout wedges the GPU (and all that entails). New code just says "meh
I'll just carry on regardless".


alan: So i did trace back the gt->wakeref before i posted these patches and
see that within these runtime get/put calls, i believe the first 'get' leads
to __intel_wakeref_get_first which calls intel_runtime_pm_get via rpm_get
helper and eventually executes a pm_runtime_get_sync(rpm->kdev); (hanging off
i915_device). (naturally there is a corresponding mirros for the '_put_last').
So this means the first-get and last-put lets the kernel know. Thats why when
i tested this patch, it did actually cause the suspend to abort from kernel side
and the kernel would print a message indicating i915 was the one that didnt
release all refs.


Ah that would be much better then.

Do you know if everything gets resumed/restored correctly in that case 
or we would need some additional work to maybe early exit from callers 
of wait_for_suspend()?


What I would also ask is to see if something like injecting a probing 
failure is feasible, so we can have this new timeout exit path 
constantly/regularly tested in CI.


Regards,

Tvrtko


alan: Anyways, i have pulled this patch out of rev6 of this series and created a
separate standalone patch for this patch #3 that we review independently.

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

2023-11-14 Thread Teres Alexis, Alan Previn

On Tue, 2023-11-14 at 17:27 +, Tvrtko Ursulin wrote:
> On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:
> > On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:
> > > On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:
> > > > On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
> > > > > On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
alan: snip
> 
> > alan: I won't say its NOT fixing anything - i am saying it's not fixing
> > this specific bug where we have the outstanding G2H from a context 
> > destruction
> > operation that got dropped. I am okay with dropping this patch in the next 
> > rev
> > but shall post a separate stand alone version of Patch3 - because I believe
> > all other i915 subsystems that take runtime-pm's DO NOT wait forever when 
> > entering
> > suspend - but GT is doing this. This means if there ever was a bug 
> > introduced,
> > it would require serial port or ramoops collection to debug. So i think 
> > such a
> > patch, despite not fixing this specific bug will be very helpful for 
> > debuggability
> > of future issues. After all, its better to fail our suspend when we have a 
> > bug
> > rather than to hang the kernel forever.
> 
> Issue I have is that I am not seeing how it fails the suspend when 
> nothing is passed out from *void* wait_suspend(gt). To me it looks the 
> suspend just carries on. And if so, it sounds dangerous to allow it to 
> do that with any future/unknown bugs in the suspend sequence. Existing 
> timeout wedges the GPU (and all that entails). New code just says "meh 
> I'll just carry on regardless".

alan: So i did trace back the gt->wakeref before i posted these patches and
see that within these runtime get/put calls, i believe the first 'get' leads
to __intel_wakeref_get_first which calls intel_runtime_pm_get via rpm_get
helper and eventually executes a pm_runtime_get_sync(rpm->kdev); (hanging off
i915_device). (naturally there is a corresponding mirros for the '_put_last').
So this means the first-get and last-put lets the kernel know. Thats why when
i tested this patch, it did actually cause the suspend to abort from kernel side
and the kernel would print a message indicating i915 was the one that didnt
release all refs.

alan: Anyways, i have pulled this patch out of rev6 of this series and created a
separate standalone patch for this patch #3 that we review independently.

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

2023-11-14 Thread Rodrigo Vivi

On Tue, Nov 14, 2023 at 05:27:18PM +, Tvrtko Ursulin wrote:
> 
> On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:
> > On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:
> > > On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:
> > > > On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
> > > > > On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
> > alan:snip
> > > > > It is not possible to wait for lost G2H in something like
> > > > > intel_uc_suspend() and simply declare "bad things happened" if it 
> > > > > times
> > > > > out there, and forcibly clean it all up? (Which would include 
> > > > > releasing
> > > > > all the abandoned pm refs, so this patch wouldn't be needed.)
> > > > > 
> > > > alan: I'm not sure if intel_uc_suspend should be held up by gt-level 
> > > > wakeref
> > > > check unless huc/guc/gsc-uc are the only ones ever taking a gt wakeref.
> > > > 
> > > > As we already know, what we do know from a uc-perspective:
> > > > -  ensure the outstanding guc related workers is flushed which we didnt 
> > > > before
> > > > (addressed by patch #1).
> > > > - any further late H2G-SchedDisable is not leaking wakerefs when 
> > > > calling H2G
> > > > and not realizing it failed (addressed by patch #2).
> > > > - (we already), "forcibly clean it all up" at the end of the 
> > > > intel_uc_suspend
> > > > when we do the guc reset and cleanup all guc-ids. (pre-existing 
> > > > upstream code)
> > > > - we previously didnt have a coherrent guarantee that "this is the end" 
> > > > i.e. no
> > > > more new request after intel_uc_suspend. I mean by code logic, we 
> > > > thought we did
> > > > (thats why intel_uc_suspend ends wth a guc reset), but we now know 
> > > > otherwise.
> > > > So we that fix by adding the additional rcu_barrier (also part of patch 
> > > > #2).
> > > 
> > > It is not clear to me from the above if that includes cleaning up the
> > > outstanding CT replies or no. But anyway..
> > alan: Apologies, i should have made it clearer by citing the actual function
> > name calling out the steps of interest: So if you look at the function
> > "intel_gt_suspend_late", it calls "intel_uc_suspend" which in turn calls
> > "intel_guc_suspend" which does a soft reset onto guc firmware - so after 
> > that
> > we can assume all outstanding G2Hs are done. Going back up the stack,
> > intel_gt_suspend_late finally calls gt_sanitize which calls 
> > "intel_uc_reset_prepare"
> > which calls "intel_guc_submission_reset_prepare" which calls
> > "scrub_guc_desc_for_outstanding_g2h" which does what we are looking for for 
> > all
> > types of outstanding G2H. As per prior review comments, besides closing the 
> > race
> > condition, we were missing an rcu_barrier (which caused new requests to 
> > come in way
> > late). So we have resolved both in Patch #2.
> 
> Cool, I read this as all known bugs are fixed by first two patches.
> 
> > > > That said, patch-3 is NOT fixing a bug in guc -its about "if we ever 
> > > > have
> > > > a future racy gt-wakeref late-leak somewhere - no matter which subsystem
> > > > took it (guc is not the only subsystem taking gt wakerefs), we at
> > > > least don't hang forever in this code. Ofc, based on that, even without
> > > > patch-3 i am confident the issue is resolved anyway.
> > > > So we could just drop patch-3 is you prefer?
> > > 
> > > .. given this it does sound to me that if you are confident patch 3
> > > isn't fixing anything today that it should be dropped.
> > alan: I won't say its NOT fixing anything - i am saying it's not fixing
> > this specific bug where we have the outstanding G2H from a context 
> > destruction
> > operation that got dropped. I am okay with dropping this patch in the next 
> > rev
> > but shall post a separate stand alone version of Patch3 - because I believe
> > all other i915 subsystems that take runtime-pm's DO NOT wait forever when 
> > entering
> > suspend - but GT is doing this. This means if there ever was a bug 
> > introduced,
> > it would require serial port or ramoops collection to debug. So i think 
> > such a
> > patch, despite not fixing this specific bug will be very helpful for 
> > debuggability
> > of future issues. After all, its better to fail our suspend when we have a 
> > bug
> > rather than to hang the kernel forever.
> 
> Issue I have is that I am not seeing how it fails the suspend when nothing
> is passed out from *void* wait_suspend(gt). To me it looks the suspend just
> carries on. And if so, it sounds dangerous to allow it to do that with any
> future/unknown bugs in the suspend sequence. Existing timeout wedges the GPU
> (and all that entails). New code just says "meh I'll just carry on
> regardless".

That's a good point.
Well, current code is already bad and buggy on suspend-resume. We could get
suspend stuck forever without any clue of what happened.
At least the proposed patch add some gt_warn. But, yes, the right thing
to do should be entirely abort the suspend in case

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

2023-11-14 Thread Tvrtko Ursulin




On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:

On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:

On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:

On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:

On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:

alan:snip

It is not possible to wait for lost G2H in something like
intel_uc_suspend() and simply declare "bad things happened" if it times
out there, and forcibly clean it all up? (Which would include releasing
all the abandoned pm refs, so this patch wouldn't be needed.)


alan: I'm not sure if intel_uc_suspend should be held up by gt-level wakeref
check unless huc/guc/gsc-uc are the only ones ever taking a gt wakeref.

As we already know, what we do know from a uc-perspective:
-  ensure the outstanding guc related workers is flushed which we didnt before
(addressed by patch #1).
- any further late H2G-SchedDisable is not leaking wakerefs when calling H2G
and not realizing it failed (addressed by patch #2).
- (we already), "forcibly clean it all up" at the end of the intel_uc_suspend
when we do the guc reset and cleanup all guc-ids. (pre-existing upstream code)
- we previously didnt have a coherrent guarantee that "this is the end" i.e. no
more new request after intel_uc_suspend. I mean by code logic, we thought we did
(thats why intel_uc_suspend ends wth a guc reset), but we now know otherwise.
So we that fix by adding the additional rcu_barrier (also part of patch #2).


It is not clear to me from the above if that includes cleaning up the
outstanding CT replies or no. But anyway..

alan: Apologies, i should have made it clearer by citing the actual function
name calling out the steps of interest: So if you look at the function
"intel_gt_suspend_late", it calls "intel_uc_suspend" which in turn calls
"intel_guc_suspend" which does a soft reset onto guc firmware - so after that
we can assume all outstanding G2Hs are done. Going back up the stack,
intel_gt_suspend_late finally calls gt_sanitize which calls 
"intel_uc_reset_prepare"
which calls "intel_guc_submission_reset_prepare" which calls
"scrub_guc_desc_for_outstanding_g2h" which does what we are looking for for all
types of outstanding G2H. As per prior review comments, besides closing the race
condition, we were missing an rcu_barrier (which caused new requests to come in 
way
late). So we have resolved both in Patch #2.


Cool, I read this as all known bugs are fixed by first two patches.


That said, patch-3 is NOT fixing a bug in guc -its about "if we ever have
a future racy gt-wakeref late-leak somewhere - no matter which subsystem
took it (guc is not the only subsystem taking gt wakerefs), we at
least don't hang forever in this code. Ofc, based on that, even without
patch-3 i am confident the issue is resolved anyway.
So we could just drop patch-3 is you prefer?


.. given this it does sound to me that if you are confident patch 3
isn't fixing anything today that it should be dropped.

alan: I won't say its NOT fixing anything - i am saying it's not fixing
this specific bug where we have the outstanding G2H from a context destruction
operation that got dropped. I am okay with dropping this patch in the next rev
but shall post a separate stand alone version of Patch3 - because I believe
all other i915 subsystems that take runtime-pm's DO NOT wait forever when 
entering
suspend - but GT is doing this. This means if there ever was a bug introduced,
it would require serial port or ramoops collection to debug. So i think such a
patch, despite not fixing this specific bug will be very helpful for 
debuggability
of future issues. After all, its better to fail our suspend when we have a bug
rather than to hang the kernel forever.


Issue I have is that I am not seeing how it fails the suspend when 
nothing is passed out from *void* wait_suspend(gt). To me it looks the 
suspend just carries on. And if so, it sounds dangerous to allow it to 
do that with any future/unknown bugs in the suspend sequence. Existing 
timeout wedges the GPU (and all that entails). New code just says "meh 
I'll just carry on regardless".


Regards,

Tvrtko

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Jani Nikula

On Tue, 14 Nov 2023, Takashi Iwai  wrote:
> (Also thought that drm-tip or whatever tree also drags the recent
> changes from sound.git tree for relevant part.)

We've dropped the sound branches from drm-tip, mostly because they were
repeatedly rebased on Linus' master (as opposed to tags) during the
merge window.

BR,
Jani.

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH] drm/i915/gsc: Assign a uabi class number to the GSC CS

2023-11-14 Thread Tvrtko Ursulin




On 14/11/2023 17:03, Daniele Ceraolo Spurio wrote:

On 11/13/2023 8:46 AM, Tvrtko Ursulin wrote:

On 13/11/2023 15:51, Daniele Ceraolo Spurio wrote:

On 11/10/2023 4:00 AM, Tvrtko Ursulin wrote:


On 09/11/2023 23:53, Daniele Ceraolo Spurio wrote:

The GSC CS is not exposed to the user, so we skipped assigning a uabi
class number for it. However, the trace logs use the uabi class and
instance to identify the engine, so leaving uabi class unset makes the
GSC CS show up as the RCS in those logs.
Given that the engine is not exposed to the user, we can't add a new
case in the uabi enum, so we insted internally define a kernel
reserved class using the next free number.

Fixes: 194babe26bdc ("drm/i915/mtl: don't expose GSC command 
streamer to the user")
Signed-off-by: Daniele Ceraolo Spurio 


Cc: Tvrtko Ursulin 
Cc: Alan Previn 
Cc: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_engine_user.c | 17 -
  drivers/gpu/drm/i915/gt/intel_engine_user.h |  4 
  drivers/gpu/drm/i915/i915_drm_client.h  |  2 +-
  drivers/gpu/drm/i915/i915_drv.h |  2 +-
  4 files changed, 14 insertions(+), 11 deletions(-)

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

index 118164ddbb2e..3fd32bedd6e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -47,6 +47,7 @@ static const u8 uabi_classes[] = {
  [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
  [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
  [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
+    [OTHER_CLASS] = I915_KERNEL_RSVD_CLASS,


Could we set it to -1 (aka no uabi class) to avoid needing to 
maintain the new macros?


And then just teach intel_engines_driver_register to skip -1. Would 
also need teaching engine_rename to handle -1.


Might end up a smaller and more maintainable patch - worth a try do 
you think?


That was my initial idea as well, but the issue with this approach is 
the engine_uabi_class_count[] array, which is sized based on the 
number of uabi classes, so having class -1 would needlessly increase 
its size a lot even when using a u8. I thought about limiting the 
class entry to 3 


I was thinking the -1 entry wouldn't be in that array since -1 is not 
uabi class by its very definition. It is not reachable from the 
outside so no need to be there.


The issue there is that the array is used to assign uabi_instance, but I 
can hardcode that to 0 for now since we don't expect any new engines of 
that class. would that work for you?


My issue is that the starting position here is GSC engine has no uabi 
class, therefore it shouldn't have an uabi instance either, therefore 
the fact you cannot use the array called engine_*uabi*_class_count to 
assign it something which it shouldn't have, shouldn't be an argument. ;)



Otherwise I'll try the 3-bits thing and see how that looks.


3-bits.. I have to admit I don't know what you mean by that?

I can try to sketch out tomorrow what I have in mind. Lets go from 
there. I might fail and concede there is nothing to be gained by using a 
different approach.


Regards,

Tvrtko



Daniele



bits so the array would max out at 8 entries, but that seemed to be 
getting a bit too convoluted. I can give it a go if you think it's be 
cleaner overall.


I had a feeling it would be, but without trying it out I won't claim 
100%.


Note that this patch does not introduce any new macros that would 
need to be maintained. I915_LAST_UABI_ENGINE_CLASS already existed (I 
just moved it from one file to another) and is the only one that 
changes when a new "real" uabi class is added; the other defines are 
based on this one. This also implies that if a new uabi class is 
added then I915_KERNEL_RSVD_CLASS would be bumped to the next free 
number, which would cause the GSC to show as a different uabi class 
in newer logs; considering that i915 is on its way out, a new class 
seems very unlikely so I thought it'd be an acceptable compromise to 
keep things simple.





  };
    static int engine_cmp(void *priv, const struct list_head *A,
@@ -138,7 +139,7 @@ const char *intel_engine_class_repr(u8 class)
  [COPY_ENGINE_CLASS] = "bcs",
  [VIDEO_DECODE_CLASS] = "vcs",
  [VIDEO_ENHANCEMENT_CLASS] = "vecs",
-    [OTHER_CLASS] = "other",
+    [OTHER_CLASS] = "gsc",


Maybe unrelated?


no. Before this patch, we hardcoded "gsc" below when calling 
engine_rename() for it. With this patch, we use the name from this 
array, so it needs to be updated. The GEM_WARN_ON below was added to 
make sure we don't get different engines in OTHER_CLASS that might 
not match the "gsc" naming.


Ah okay, one special casing for another, a wash I guess.

Regards,

Tvrtko



Regards,

Tvrtko


  [COMPUTE_CLASS] = "ccs",
  };
  @@ -216,14 +217,8 @@ void intel_engines_driver_register(struct 
drm_i915_private *i915)

  if

Re: [Intel-gfx] [PATCH] drm/i915/gsc: Assign a uabi class number to the GSC CS

2023-11-14 Thread Daniele Ceraolo Spurio





On 11/13/2023 8:46 AM, Tvrtko Ursulin wrote:


On 13/11/2023 15:51, Daniele Ceraolo Spurio wrote:

On 11/10/2023 4:00 AM, Tvrtko Ursulin wrote:


On 09/11/2023 23:53, Daniele Ceraolo Spurio wrote:

The GSC CS is not exposed to the user, so we skipped assigning a uabi
class number for it. However, the trace logs use the uabi class and
instance to identify the engine, so leaving uabi class unset makes the
GSC CS show up as the RCS in those logs.
Given that the engine is not exposed to the user, we can't add a new
case in the uabi enum, so we insted internally define a kernel
reserved class using the next free number.

Fixes: 194babe26bdc ("drm/i915/mtl: don't expose GSC command 
streamer to the user")
Signed-off-by: Daniele Ceraolo Spurio 


Cc: Tvrtko Ursulin 
Cc: Alan Previn 
Cc: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_engine_user.c | 17 -
  drivers/gpu/drm/i915/gt/intel_engine_user.h |  4 
  drivers/gpu/drm/i915/i915_drm_client.h  |  2 +-
  drivers/gpu/drm/i915/i915_drv.h |  2 +-
  4 files changed, 14 insertions(+), 11 deletions(-)

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

index 118164ddbb2e..3fd32bedd6e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -47,6 +47,7 @@ static const u8 uabi_classes[] = {
  [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
  [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
  [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
+    [OTHER_CLASS] = I915_KERNEL_RSVD_CLASS,


Could we set it to -1 (aka no uabi class) to avoid needing to 
maintain the new macros?


And then just teach intel_engines_driver_register to skip -1. Would 
also need teaching engine_rename to handle -1.


Might end up a smaller and more maintainable patch - worth a try do 
you think?


That was my initial idea as well, but the issue with this approach is 
the engine_uabi_class_count[] array, which is sized based on the 
number of uabi classes, so having class -1 would needlessly increase 
its size a lot even when using a u8. I thought about limiting the 
class entry to 3 


I was thinking the -1 entry wouldn't be in that array since -1 is not 
uabi class by its very definition. It is not reachable from the 
outside so no need to be there.


The issue there is that the array is used to assign uabi_instance, but I 
can hardcode that to 0 for now since we don't expect any new engines of 
that class. would that work for you?

Otherwise I'll try the 3-bits thing and see how that looks.

Daniele



bits so the array would max out at 8 entries, but that seemed to be 
getting a bit too convoluted. I can give it a go if you think it's be 
cleaner overall.


I had a feeling it would be, but without trying it out I won't claim 
100%.


Note that this patch does not introduce any new macros that would 
need to be maintained. I915_LAST_UABI_ENGINE_CLASS already existed (I 
just moved it from one file to another) and is the only one that 
changes when a new "real" uabi class is added; the other defines are 
based on this one. This also implies that if a new uabi class is 
added then I915_KERNEL_RSVD_CLASS would be bumped to the next free 
number, which would cause the GSC to show as a different uabi class 
in newer logs; considering that i915 is on its way out, a new class 
seems very unlikely so I thought it'd be an acceptable compromise to 
keep things simple.





  };
    static int engine_cmp(void *priv, const struct list_head *A,
@@ -138,7 +139,7 @@ const char *intel_engine_class_repr(u8 class)
  [COPY_ENGINE_CLASS] = "bcs",
  [VIDEO_DECODE_CLASS] = "vcs",
  [VIDEO_ENHANCEMENT_CLASS] = "vecs",
-    [OTHER_CLASS] = "other",
+    [OTHER_CLASS] = "gsc",


Maybe unrelated?


no. Before this patch, we hardcoded "gsc" below when calling 
engine_rename() for it. With this patch, we use the name from this 
array, so it needs to be updated. The GEM_WARN_ON below was added to 
make sure we don't get different engines in OTHER_CLASS that might 
not match the "gsc" naming.


Ah okay, one special casing for another, a wash I guess.

Regards,

Tvrtko



Regards,

Tvrtko


  [COMPUTE_CLASS] = "ccs",
  };
  @@ -216,14 +217,8 @@ void intel_engines_driver_register(struct 
drm_i915_private *i915)

  if (intel_gt_has_unrecoverable_error(engine->gt))
  continue; /* ignore incomplete engines */
  -    /*
- * We don't want to expose the GSC engine to the users, 
but we
- * still rename it so it is easier to identify in the 
debug logs

- */
-    if (engine->id == GSC0) {
-    engine_rename(engine, "gsc", 0);
-    continue;
-    }
+    /* The only engine we expect in OTHER_CLASS is GSC0 */
+    GEM_WARN_ON(engine->class == OTHER_CLASS && engine->id != 
GSC0);

    GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Takashi Iwai

On Tue, 14 Nov 2023 14:31:25 +0100,
Saarinen, Jani wrote:
> 
> Hi, 
> > -Original Message-
> > From: Maarten Lankhorst 
> > Sent: Tuesday, November 14, 2023 3:30 PM
> > To: Jani Nikula ; Ville Syrjälä
> > 
> > Cc: Takashi Iwai ; intel-gfx@lists.freedesktop.org; intel-
> > x...@lists.freedesktop.org; alsa-de...@alsa-project.org; Saarinen, Jani
> > ; Kurmi, Suresh Kumar
> > 
> > Subject: Re: [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move 
> > snd_hdac_i915_init
> > to before probe_work.
> > 
> > Hey,
> > 
> > Den 2023-11-14 kl. 13:35, skrev Jani Nikula:
> > > On Tue, 14 Nov 2023, Ville Syrjälä  wrote:
> > >> On Mon, Oct 02, 2023 at 09:38:44PM +0200,
> > maarten.lankho...@linux.intel.com wrote:
> > >>> From: Maarten Lankhorst 
> > >>>
> > >>> Now that we can use -EPROBE_DEFER, it's no longer required to spin
> > >>> off the snd_hdac_i915_init into a workqueue.
> > >>>
> > >>> Use the -EPROBE_DEFER mechanism instead, which must be returned in
> > >>> the probe function.
> > >> This completely broke i915 audio!
> > >>
> > >> I also can't see any trace of this stuff ever being posted to
> > >> intel-gfx so it never went through the CI.
> > >>
> > >> Please fix or revert ASAP.
> > > Cc: Jani, Suresh
> > >
> > > Ville, please file a bug at gitlab so we can track this, thanks.
> > 
> > I've originally tested this on TGL and DG2, so can you be more specific on 
> > what
> > broke?
> Was this series tested on CI  ever as Ville saying no? How this got merged? 

Hm, I somehow believed that patches have been tested by intel people,
as they came from intel.  (Also thought that drm-tip or whatever tree
also drags the recent changes from sound.git tree for relevant part.)

In anyway, the whole patches were touching only sound/* files and no
changes in DRM side at all, hence they weren't sent to intel-gfx, I
suppose.


Takashi

Re: [Intel-gfx] [PATCH] drm/i915/display: keep struct intel_display members sorted

2023-11-14 Thread Rodrigo Vivi

On Tue, Nov 14, 2023 at 05:55:28PM +0200, Jani Nikula wrote:
> Like the comment says,
> 
>   /* Grouping using anonymous structs. Keep sorted. */
> 
> Stick to it.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Rodrigo Vivi 

> ---
>  .../gpu/drm/i915/display/intel_display_core.h  | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
> b/drivers/gpu/drm/i915/display/intel_display_core.h
> index aa8be02c9e54..7e82b87e9cde 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
> @@ -348,15 +348,6 @@ struct intel_display {
>   struct intel_global_obj obj;
>   } dbuf;
>  
> - struct {
> - wait_queue_head_t waitqueue;
> -
> - /* mutex to protect pmdemand programming sequence */
> - struct mutex lock;
> -
> - struct intel_global_obj obj;
> - } pmdemand;
> -
>   struct {
>   /*
>* dkl.phy_lock protects against concurrent access of the
> @@ -444,6 +435,15 @@ struct intel_display {
>   bool false_color;
>   } ips;
>  
> + struct {
> + wait_queue_head_t waitqueue;
> +
> + /* mutex to protect pmdemand programming sequence */
> + struct mutex lock;
> +
> + struct intel_global_obj obj;
> + } pmdemand;
> +
>   struct {
>   struct i915_power_domains domains;
>  
> -- 
> 2.39.2
>

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: do not clean GT table on error path

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915: do not clean GT table on error path
URL   : https://patchwork.freedesktop.org/series/126385/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13873 -> Patchwork_126385v1


Summary
---

  **FAILURE**

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

Participating hosts (37 -> 39)
--

  Additional (4): fi-kbl-soraka bat-rpls-1 bat-kbl-2 bat-dg2-9 
  Missing(2): fi-snb-2520m fi-pnv-d510 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@workarounds:
- bat-adlp-9: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13873/bat-adlp-9/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v1/bat-adlp-9/igt@i915_selftest@l...@workarounds.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-atsm-1: [PASS][3] -> [WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13873/bat-atsm-1/igt@i915_susp...@basic-s2idle-without-i915.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v1/bat-atsm-1/igt@i915_susp...@basic-s2idle-without-i915.html

  
Known issues


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

### CI changes ###

 Issues hit 

  * boot:
- bat-jsl-1:  [PASS][5] -> [FAIL][6] ([i915#8293])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13873/bat-jsl-1/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v1/bat-jsl-1/boot.html

  

### IGT changes ###

 Issues hit 

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

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

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

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

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][13] ([fdo#109271]) +24 other tests 
skip
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v1/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- bat-rpls-1: NOTRUN -> [SKIP][14] ([i915#4613]) +3 other tests skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126385v1/bat-rpls-1/igt@gem_lmem_swapp...@random-engines.html

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

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

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

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

  * igt@i915_pm_rps@basic-api:
- bat-dg2-9:  NOTRUN -> [SKIP][19] ([i915#6621])
   [19]:

[Intel-gfx] [PATCH v1 1/1] drm/i915/gt: Dont wait forever when idling in suspend

2023-11-14 Thread Alan Previn

When suspending, add a timeout when calling
intel_gt_pm_wait_for_idle else if we have a leaked
wakeref (which would be indicative of a bug elsewhere
in the driver), driver will at exit the suspend-resume
cycle, after the kernel detects the held reference and
prints a message to abort suspending instead of hanging
in the kernel forever which then requires serial connection
or ramoops dump to debug further.

Signed-off-by: Alan Previn 
Reviewed-by: Rodrigo Vivi 
Tested-by: Mousumi Jana 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |  7 ++-
 drivers/gpu/drm/i915/gt/intel_gt_pm.h |  7 ++-
 drivers/gpu/drm/i915/intel_wakeref.c  | 14 ++
 drivers/gpu/drm/i915/intel_wakeref.h  |  6 --
 5 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 40687806d22a..ffef963037f2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -686,7 +686,7 @@ void intel_engines_release(struct intel_gt *gt)
if (!engine->release)
continue;
 
-   intel_wakeref_wait_for_idle(>wakeref);
+   intel_wakeref_wait_for_idle(>wakeref, 0);
GEM_BUG_ON(intel_engine_pm_is_awake(engine));
 
engine->release(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index f5899d503e23..25cb39ba9fdf 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -306,6 +306,8 @@ int intel_gt_resume(struct intel_gt *gt)
 
 static void wait_for_suspend(struct intel_gt *gt)
 {
+   int final_timeout_ms = (I915_GT_SUSPEND_IDLE_TIMEOUT * 10);
+
if (!intel_gt_pm_is_awake(gt))
return;
 
@@ -318,7 +320,10 @@ static void wait_for_suspend(struct intel_gt *gt)
intel_gt_retire_requests(gt);
}
 
-   intel_gt_pm_wait_for_idle(gt);
+   /* we are suspending, so we shouldn't be waiting forever */
+   if (intel_gt_pm_wait_timeout_for_idle(gt, final_timeout_ms) == 
-ETIMEDOUT)
+   gt_warn(gt, "bailing from %s after %d milisec timeout\n",
+   __func__, final_timeout_ms);
 }
 
 void intel_gt_suspend_prepare(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index b1eeb5b33918..1757ca4c3077 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -68,7 +68,12 @@ static inline void intel_gt_pm_might_put(struct intel_gt *gt)
 
 static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
 {
-   return intel_wakeref_wait_for_idle(>wakeref);
+   return intel_wakeref_wait_for_idle(>wakeref, 0);
+}
+
+static inline int intel_gt_pm_wait_timeout_for_idle(struct intel_gt *gt, int 
timeout_ms)
+{
+   return intel_wakeref_wait_for_idle(>wakeref, timeout_ms);
 }
 
 void intel_gt_pm_init_early(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/intel_wakeref.c 
b/drivers/gpu/drm/i915/intel_wakeref.c
index 623a69089386..f2611c65246b 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.c
+++ b/drivers/gpu/drm/i915/intel_wakeref.c
@@ -113,14 +113,20 @@ void __intel_wakeref_init(struct intel_wakeref *wf,
 "wakeref.work", >work, 0);
 }
 
-int intel_wakeref_wait_for_idle(struct intel_wakeref *wf)
+int intel_wakeref_wait_for_idle(struct intel_wakeref *wf, int timeout_ms)
 {
-   int err;
+   int err = 0;
 
might_sleep();
 
-   err = wait_var_event_killable(>wakeref,
- !intel_wakeref_is_active(wf));
+   if (!timeout_ms)
+   err = wait_var_event_killable(>wakeref,
+ !intel_wakeref_is_active(wf));
+   else if (wait_var_event_timeout(>wakeref,
+   !intel_wakeref_is_active(wf),
+   msecs_to_jiffies(timeout_ms)) < 1)
+   err = -ETIMEDOUT;
+
if (err)
return err;
 
diff --git a/drivers/gpu/drm/i915/intel_wakeref.h 
b/drivers/gpu/drm/i915/intel_wakeref.h
index ec881b097368..302694a780d2 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.h
+++ b/drivers/gpu/drm/i915/intel_wakeref.h
@@ -251,15 +251,17 @@ __intel_wakeref_defer_park(struct intel_wakeref *wf)
 /**
  * intel_wakeref_wait_for_idle: Wait until the wakeref is idle
  * @wf: the wakeref
+ * @timeout_ms: Timeout in ms, 0 means never timeout.
  *
  * Wait for the earlier asynchronous release of the wakeref. Note
  * this will wait for any third party as well, so make sure you only wait
  * when you have control over the wakeref and trust no one else is acquiring
  * it.
  *
- * Return: 0 on success, error code if killed.
+ * Returns 0 on success, -ETIMEDOUT upon a timeout, or the unlikely
+ *

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: do not clean GT table on error path

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915: do not clean GT table on error path
URL   : https://patchwork.freedesktop.org/series/126385/
State : warning

== Summary ==

Error: dim checkpatch failed
272a68a547e9 drm/i915: do not clean GT table on error path
-:14: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75 chars per line 
(possible unwrapped commit description?)
#14: 
BUG i915_request (...): Objects remaining in i915_request on 
__kmem_cache_shutdown()

-:27: WARNING:BAD_FIXES_TAG: Please use correct Fixes: style 'Fixes: <12 chars 
of sha1> ("")' - ie: 'Fixes: bec68cc9ea42 ("drm/i915: Prepare for 
multiple GTs")'
#27: 
Fixes: bec68cc9ea42d8 ("drm/i915: Prepare for multiple GTs")

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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Tune down FEC detection timeout error message

2023-11-14 Thread Imre Deak

On Tue, Nov 14, 2023 at 04:56:35AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/dp: Tune down FEC detection timeout error message
> URL   : https://patchwork.freedesktop.org/series/126340/
> State : success

Patch is pushed to -din, thanks for the review.

> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_13870_full -> Patchwork_126340v1_full
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 
>   
> 
> Participating hosts (11 -> 10)
> --
> 
>   Missing(1): shard-mtlp0 
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_126340v1_full:
> 
> ### IGT changes ###
> 
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * {igt@drm_buddy@drm_buddy@drm_test_buddy_alloc_pessimistic}:
> - shard-rkl:  [PASS][1] -> [TIMEOUT][2] +3 other tests timeout
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-rkl-7/igt@drm_buddy@drm_buddy@drm_test_buddy_alloc_pessimistic.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126340v1/shard-rkl-7/igt@drm_buddy@drm_buddy@drm_test_buddy_alloc_pessimistic.html
> - shard-snb:  [PASS][3] -> [TIMEOUT][4]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-snb5/igt@drm_buddy@drm_buddy@drm_test_buddy_alloc_pessimistic.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126340v1/shard-snb5/igt@drm_buddy@drm_buddy@drm_test_buddy_alloc_pessimistic.html
> 
>   * 
> {igt@kms_selftest@drm_damage_helper@drm_test_damage_iter_single_damage_src_moved}:
> - shard-apl:  [PASS][5] -> [TIMEOUT][6] +1 other test timeout
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-apl4/igt@kms_selftest@drm_damage_helper@drm_test_damage_iter_single_damage_src_moved.html
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126340v1/shard-apl7/igt@kms_selftest@drm_damage_helper@drm_test_damage_iter_single_damage_src_moved.html
> 
>   * 
> {igt@kms_selftest@drm_dp_mst_helper@drm_test_dp_mst_sideband_msg_req_decode}:
> - shard-tglu: [PASS][7] -> [TIMEOUT][8]
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-tglu-8/igt@kms_selftest@drm_dp_mst_helper@drm_test_dp_mst_sideband_msg_req_decode.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126340v1/shard-tglu-2/igt@kms_selftest@drm_dp_mst_helper@drm_test_dp_mst_sideband_msg_req_decode.html
> 
>   * {igt@kms_selftest@drm_framebuffer@drm_test_framebuffer_create}:
> - shard-dg1:  [PASS][9] -> [TIMEOUT][10]
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-dg1-12/igt@kms_selftest@drm_framebuffer@drm_test_framebuffer_create.html
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126340v1/shard-dg1-12/igt@kms_selftest@drm_framebuffer@drm_test_framebuffer_create.html
> 
>   * {igt@kms_selftest@drm_plane_helper@drm_test_check_invalid_plane_state}:
> - shard-glk:  [PASS][11] -> [TIMEOUT][12]
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-glk5/igt@kms_selftest@drm_plane_helper@drm_test_check_invalid_plane_state.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126340v1/shard-glk9/igt@kms_selftest@drm_plane_helper@drm_test_check_invalid_plane_state.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_126340v1_full that come from known 
> issues:
> 
> ### CI changes ###
> 
>  Issues hit 
> 
>   * boot:
> - shard-apl:  ([PASS][13], [PASS][14], [PASS][15], [PASS][16], 
> [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], 
> [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], 
> [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], 
> [PASS][35], [PASS][36], [PASS][37]) -> ([PASS][38], [PASS][39], [PASS][40], 
> [PASS][41], [PASS][42], [PASS][43], [PASS][44], [FAIL][45], [PASS][46], 
> [FAIL][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], 
> [PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58], 
> [PASS][59], [PASS][60], [PASS][61], [PASS][62]) ([i915#8293])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-apl4/boot.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-apl4/boot.html
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-apl4/boot.html
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-apl4/boot.html
>[17]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-apl7/boot.html
>[18]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13870/shard-apl7/boot.html
>[19]: 
>

[Intel-gfx] [PATCH] drm/i915/display: keep struct intel_display members sorted

2023-11-14 Thread Jani Nikula

Like the comment says,

/* Grouping using anonymous structs. Keep sorted. */

Stick to it.

Signed-off-by: Jani Nikula 
---
 .../gpu/drm/i915/display/intel_display_core.h  | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index aa8be02c9e54..7e82b87e9cde 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -348,15 +348,6 @@ struct intel_display {
struct intel_global_obj obj;
} dbuf;
 
-   struct {
-   wait_queue_head_t waitqueue;
-
-   /* mutex to protect pmdemand programming sequence */
-   struct mutex lock;
-
-   struct intel_global_obj obj;
-   } pmdemand;
-
struct {
/*
 * dkl.phy_lock protects against concurrent access of the
@@ -444,6 +435,15 @@ struct intel_display {
bool false_color;
} ips;
 
+   struct {
+   wait_queue_head_t waitqueue;
+
+   /* mutex to protect pmdemand programming sequence */
+   struct mutex lock;
+
+   struct intel_global_obj obj;
+   } pmdemand;
+
struct {
struct i915_power_domains domains;
 
-- 
2.39.2

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: move *_crtc_clock_get() to intel_dpll.c (rev2)

2023-11-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/4] drm/i915: move *_crtc_clock_get() to 
intel_dpll.c (rev2)
URL   : https://patchwork.freedesktop.org/series/126345/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13873 -> Patchwork_126345v2


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (37 -> 36)
--

  Additional (3): bat-rpls-1 bat-kbl-2 bat-dg2-9 
  Missing(4): fi-hsw-4770 bat-mtlp-8 fi-snb-2520m fi-bsw-n3050 

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@gem_lmem_swapping@parallel-random-engines:
- bat-kbl-2:  NOTRUN -> [SKIP][5] ([fdo#109271]) +24 other tests 
skip
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126345v2/bat-kbl-2/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@random-engines:
- bat-rpls-1: NOTRUN -> [SKIP][6] ([i915#4613]) +3 other tests skip
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126345v2/bat-rpls-1/igt@gem_lmem_swapp...@random-engines.html

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

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

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

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

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

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

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

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

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

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

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

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][19] ([i915#4103] / [i915#4213] / 
[i915#5608]) +1 other test skip
   [19]:

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Maarten Lankhorst


Hey,

Den 2023-11-14 kl. 16:50, skrev Takashi Iwai:

On Tue, 14 Nov 2023 15:39:16 +0100,
Maarten Lankhorst wrote:


Hey,

Den 2023-11-14 kl. 14:39, skrev Ville Syrjälä:

 On Tue, Nov 14, 2023 at 02:35:10PM +0200, Jani Nikula wrote:
 
 On Tue, 14 Nov 2023, Ville Syrjälä  wrote:
 
 On Mon, Oct 02, 2023 at 09:38:44PM +0200, maarten.lankho...@linux.intel.com wrote:
 
 From: Maarten Lankhorst 
 
 Now that we can use -EPROBE_DEFER, it's no longer required to spin off

 the snd_hdac_i915_init into a workqueue.
 
 Use the -EPROBE_DEFER mechanism instead, which must be returned in the

 probe function.
 
 This completely broke i915 audio!
 
 I also can't see any trace of this stuff ever being posted to

 intel-gfx so it never went through the CI.
 
 Please fix or revert ASAP.
 
 Cc: Jani, Suresh
 
 Ville, please file a bug at gitlab so we can track this, thanks.
 
 https://gitlab.freedesktop.org/drm/intel/-/issues/9671
 
Looks like a simple patch should be enough, can you test below?

Seems that we reached to the same conclusion :)

I took a quick look at other code paths, and sound/pci/hda/hda_intel.c
is the only place that needs the correction.  Other (ASoC) drivers are
either simply always returning the error or dealing only with -ENODEV
case for skipping the HDMI codec.


Yeah, the original comment in the code confused me and led me to not 
handle -EPROBE_DEFER in the first place there.


Cheers,

Maarten


thanks,

Takashi




diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 058f6e6491f9a..946aaa487f200 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2145,7 +2145,8 @@ static int azx_probe(struct pci_dev *pci,
* for other 
chips, still continue probing as other
* codecs 
can be on the same link.
*/
- if 
(HDA_CONTROLLER_IN_GPU(pci)) {
+ if 
(HDA_CONTROLLER_IN_GPU(pci) ||
+ err == 
-EPROBE_DEFER) {

 goto out_free;
   } else {

 /* don't bother any longer */

[Intel-gfx] [PATCH v6 1/2] drm/i915/guc: Flush context destruction worker at suspend

2023-11-14 Thread Alan Previn

When suspending, flush the context-guc-id
deregistration worker at the final stages of
intel_gt_suspend_late when we finally call gt_sanitize
that eventually leads down to __uc_sanitize so that
the deregistration worker doesn't fire off later as
we reset the GuC microcontroller.

Signed-off-by: Alan Previn 
Reviewed-by: Rodrigo Vivi 
Tested-by: Mousumi Jana 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 ++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d37698bd6b91..9d1915482898 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1611,6 +1611,11 @@ static void guc_flush_submissions(struct intel_guc *guc)
spin_unlock_irqrestore(_engine->lock, flags);
 }
 
+void intel_guc_submission_flush_work(struct intel_guc *guc)
+{
+   flush_work(>submission_state.destroyed_worker);
+}
+
 static void guc_flush_destroyed_contexts(struct intel_guc *guc);
 
 void intel_guc_submission_reset_prepare(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index c57b29cdb1a6..b6df75622d3b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -38,6 +38,8 @@ int intel_guc_wait_for_pending_msg(struct intel_guc *guc,
   bool interruptible,
   long timeout);
 
+void intel_guc_submission_flush_work(struct intel_guc *guc);
+
 static inline bool intel_guc_submission_is_supported(struct intel_guc *guc)
 {
return guc->submission_supported;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 27f6561dd731..cb74835b1a13 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -695,6 +695,8 @@ void intel_uc_suspend(struct intel_uc *uc)
return;
}
 
+   intel_guc_submission_flush_work(guc);
+
with_intel_runtime_pm(_to_gt(uc)->i915->runtime_pm, wakeref) {
err = intel_guc_suspend(guc);
if (err)
-- 
2.39.0

[Intel-gfx] [PATCH v6 2/2] drm/i915/guc: Close deregister-context race against CT-loss

2023-11-14 Thread Alan Previn

If we are at the end of suspend or very early in resume
its possible an async fence signal (via rcu_call) is triggered
to free_engines which could lead us to the execution of
the context destruction worker (after a prior worker flush).

Thus, when suspending, insert rcu_barriers at the start
of i915_gem_suspend (part of driver's suspend prepare) and
again in i915_gem_suspend_late so that all such cases have
completed and context destruction list isn't missing anything.

In destroyed_worker_func, close the race against CT-loss
by checking that CT is enabled before calling into
deregister_destroyed_contexts.

Based on testing, guc_lrc_desc_unpin may still race and fail
as we traverse the GuC's context-destroy list because the
CT could be disabled right before calling GuC's CT send function.

We've witnessed this race condition once every ~6000-8000
suspend-resume cycles while ensuring workloads that render
something onscreen is continuously started just before
we suspend (and the workload is small enough to complete
and trigger the queued engine/context free-up either very
late in suspend or very early in resume).

In such a case, we need to unroll the entire process because
guc-lrc-unpin takes a gt wakeref which only gets released in
the G2H IRQ reply that never comes through in this corner
case. Without the unroll, the taken wakeref is leaked and will
cascade into a kernel hang later at the tail end of suspend in
this function:

   intel_wakeref_wait_for_idle(>wakeref)
   (called by) - intel_gt_pm_wait_for_idle
   (called by) - wait_for_suspend

Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_-
contexts if guc_lrc_desc_unpin fails due to CT send falure.
When unrolling, keep the context in the GuC's destroy-list so
it can get picked up on the next destroy worker invocation
(if suspend aborted) or get fully purged as part of a GuC
sanitization (end of suspend) or a reset flow.

Signed-off-by: Alan Previn 
Signed-off-by: Anshuman Gupta 
Tested-by: Mousumi Jana 
---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ---
 2 files changed, 80 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 0d812f4d787d..3b27218aabe2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -28,6 +28,13 @@ void i915_gem_suspend(struct drm_i915_private *i915)
GEM_TRACE("%s\n", dev_name(i915->drm.dev));
 
intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
+   /*
+* On rare occasions, we've observed the fence completion triggers
+* free_engines asynchronously via rcu_call. Ensure those are done.
+* This path is only called on suspend, so it's an acceptable cost.
+*/
+   rcu_barrier();
+
flush_workqueue(i915->wq);
 
/*
@@ -160,6 +167,9 @@ void i915_gem_suspend_late(struct drm_i915_private *i915)
 * machine in an unusable condition.
 */
 
+   /* Like i915_gem_suspend, flush tasks staged from fence triggers */
+   rcu_barrier();
+
for_each_gt(gt, i915, i)
intel_gt_suspend_late(gt);
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9d1915482898..225747115f78 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -236,6 +236,13 @@ set_context_destroyed(struct intel_context *ce)
ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
 }
 
+static inline void
+clr_context_destroyed(struct intel_context *ce)
+{
+   lockdep_assert_held(>guc_state.lock);
+   ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED;
+}
+
 static inline bool context_pending_disable(struct intel_context *ce)
 {
return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
@@ -613,6 +620,8 @@ static int guc_submission_send_busy_loop(struct intel_guc 
*guc,
 u32 g2h_len_dw,
 bool loop)
 {
+   int ret;
+
/*
 * We always loop when a send requires a reply (i.e. g2h_len_dw > 0),
 * so we don't handle the case where we don't get a reply because we
@@ -623,7 +632,11 @@ static int guc_submission_send_busy_loop(struct intel_guc 
*guc,
if (g2h_len_dw)
atomic_inc(>outstanding_submission_g2h);
 
-   return intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
+   ret = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
+   if (ret)
+   atomic_dec(>outstanding_submission_g2h);
+
+   return ret;
 }
 
 int intel_guc_wait_for_pending_msg(struct intel_guc *guc,
@@ -3286,12 +3299,13 @@ static void guc_context_close(struct intel_context *ce)
spin_unlock_irqrestore(>guc_state.lock, flags);
 }
 
-static inline

[Intel-gfx] [PATCH v6 0/2] Resolve suspend-resume racing with GuC destroy-context-worker

2023-11-14 Thread Alan Previn

This series is the result of debugging issues root caused to
races between the GuC's destroyed_worker_func being triggered
vs repeating suspend-resume cycles with concurrent delayed
fence signals for engine-freeing.

The reproduction steps require that an app is launched right
before the start of the suspend cycle where it creates a
new gem context and submits a tiny workload that would
complete in the middle of the suspend cycle. However this
app uses dma-buffer sharing or dma-fence with non-GPU
objects or signals that eventually triggers a FENCE_FREE
via__i915_sw_fence_notify that connects to engines_notify ->
free_engines_rcu -> intel_context_put ->
kref_put(>ref..) that queues the worker after the GuCs
CTB has been disabled (i.e. after i915-gem's suspend-late).

This sequence is a corner-case and required repeating this
app->suspend->resume cycle ~1500 times across 4 identical
systems to see it once. That said, based on above callstack,
it is clear that merely flushing the context destruction worker,
which is obviously missing and needed, isn't sufficient.

Because of that, this series adds additional patches besides
the obvious (Patch #1) flushing of the worker during the
suspend flows. It also includes (Patch #2) closing a race
between sending the context-deregistration H2G vs the CTB
getting disabled in the midst of it (by detecing the failure
and unrolling the guc-lrc-unpin flow) and adding an additional
rcu_barrier in the gem-suspend flow to purge outstanding
rcu defered tasks that may include context destruction.

This patch was tested and confirmed to be reliably working
after running ~1500 suspend resume cycles on 4 concurrent
machines.

Changes from prior revs:
   v5: - Remove Patch #3 which doesnt solve this exact bug
 but can be a separate patch(Tvrtko).
   v4: - In Patch #2, change the position of the calls into
 rcu_barrier based on latest testing data. (Alan/Anshuman).
   - In Patch #3, fix the timeout value selection for the
 final gt-pm idle-wait that was incorrectly using a 'ns'
 #define as a milisec timeout.
   v3: - In Patch #3, when deregister_context fails, instead
 of calling intel_gt_pm_put(that might sleep), call
 __intel_wakeref_put (without ASYNC flag) (Rodrigo/Anshuman).
   - In wait_for_suspend add an rcu_barrier before we
 proceed to wait for idle. (Anshuman)
   v2: - Patch #2 Restructure code in guc_lrc_desc_unpin so
 it's more readible to differentiate (1)direct guc-id
 cleanup ..vs (2) sending the H2G ctx-destroy action ..
 vs (3) the unrolling steps if the H2G fails.
   - Patch #2 Add a check to close the race sooner by checking
 for intel_guc_is_ready from destroyed_worker_func.
   - Patch #2 When guc_submission_send_busy_loop gets a
 failure from intel_guc_send_busy_loop, we need to undo
 i.e. decrement the outstanding_submission_g2h.
   - Patch #3 In wait_for_suspend, fix checking of return from
 intel_gt_pm_wait_timeout_for_idle to now use -ETIMEDOUT
 and add documentation for intel_wakeref_wait_for_idle.
 (Rodrigo).

Alan Previn (2):
  drm/i915/guc: Flush context destruction worker at suspend
  drm/i915/guc: Close deregister-context race against CT-loss

 drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 86 ---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.h |  2 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c |  2 +
 4 files changed, 89 insertions(+), 11 deletions(-)


base-commit: 3d1e36691e73b3946b4a9ca8132a34f0319ff984
-- 
2.39.0

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Takashi Iwai

On Tue, 14 Nov 2023 15:39:16 +0100,
Maarten Lankhorst wrote:
> 
> 
> Hey,
> 
> Den 2023-11-14 kl. 14:39, skrev Ville Syrjälä:
> 
> On Tue, Nov 14, 2023 at 02:35:10PM +0200, Jani Nikula wrote:
> 
> On Tue, 14 Nov 2023, Ville Syrjälä  
> wrote:
> 
> On Mon, Oct 02, 2023 at 09:38:44PM +0200, 
> maarten.lankho...@linux.intel.com wrote:
> 
> From: Maarten Lankhorst 
> 
> Now that we can use -EPROBE_DEFER, it's no longer required to 
> spin off
> the snd_hdac_i915_init into a workqueue.
> 
> Use the -EPROBE_DEFER mechanism instead, which must be 
> returned in the
> probe function.
> 
> This completely broke i915 audio!
> 
> I also can't see any trace of this stuff ever being posted to 
> intel-gfx so it never went through the CI.
> 
> Please fix or revert ASAP.
> 
> Cc: Jani, Suresh
> 
> Ville, please file a bug at gitlab so we can track this, thanks.
> 
> https://gitlab.freedesktop.org/drm/intel/-/issues/9671
> 
> Looks like a simple patch should be enough, can you test below?

Seems that we reached to the same conclusion :)

I took a quick look at other code paths, and sound/pci/hda/hda_intel.c
is the only place that needs the correction.  Other (ASoC) drivers are
either simply always returning the error or dealing only with -ENODEV
case for skipping the HDMI codec.


thanks,

Takashi

> 
> 
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 058f6e6491f9a..946aaa487f200 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -2145,7 +2145,8 @@ static int azx_probe(struct pci_dev *pci,
>* for 
> other chips, still continue probing as other
>* codecs 
> can be on the same link.
>*/
> - if 
> (HDA_CONTROLLER_IN_GPU(pci)) {
> + if 
> (HDA_CONTROLLER_IN_GPU(pci) ||
> + err == 
> -EPROBE_DEFER) {
>   
>   goto out_free;
>   } else {
>   
>   /* don't bother any longer */
>

Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: In intel_framebuffer_init switch to use intel_bo_to_drm_bo

2023-11-14 Thread Shankar, Uma




> -Original Message-
> From: Intel-gfx  On Behalf Of Juha-
> Pekka Heikkila
> Sent: Tuesday, November 14, 2023 2:03 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915/display: In intel_framebuffer_init
> switch to use intel_bo_to_drm_bo
> 
> Use intel_bo_to_drm_bo instead of >base.

Can you elaborate the reasoning why this was introduced and what is the
rationale for switch.

With that added, for the whole series
Reviewed-by: Uma Shankar 

> Signed-off-by: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/display/intel_fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index c1777ea35761..6d48aa3af95a 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -2093,7 +2093,7 @@ int intel_framebuffer_init(struct intel_framebuffer
> *intel_fb,
>   }
>   }
> 
> - fb->obj[i] = >base;
> + fb->obj[i] = intel_bo_to_drm_bo(obj);
>   }
> 
>   ret = intel_fill_fb_info(dev_priv, intel_fb);
> --
> 2.25.1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915: move *_crtc_clock_get() to intel_dpll.c (rev2)

2023-11-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/4] drm/i915: move *_crtc_clock_get() to 
intel_dpll.c (rev2)
URL   : https://patchwork.freedesktop.org/series/126345/
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:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return'
+./arch/x86/include/asm/bitops.h:147:1: warning:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: move *_crtc_clock_get() to intel_dpll.c (rev2)

2023-11-14 Thread Patchwork

== Series Details ==

Series: series starting with [1/4] drm/i915: move *_crtc_clock_get() to 
intel_dpll.c (rev2)
URL   : https://patchwork.freedesktop.org/series/126345/
State : warning

== Summary ==

Error: dim checkpatch failed
745a45011899 drm/i915: move *_crtc_clock_get() to intel_dpll.c
-:346: CHECK:BRACES: braces {} should be used on all arms of this statement
#346: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:458:
+   if (dpll & PLL_P1_DIVIDE_BY_TWO)
[...]
+   else {
[...]

-:348: CHECK:BRACES: Unbalanced braces around else statement
#348: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:460:
+   else {

total: 0 errors, 0 warnings, 2 checks, 424 lines checked
696f9cc57a47 drm/i915: add vlv_pipe_to_phy() helper to replace DPIO_PHY()
-:57: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#57: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.h:120:
 }
+static inline enum dpio_phy vlv_pipe_to_phy(enum pipe pipe)

total: 0 errors, 0 warnings, 1 checks, 71 lines checked
1acc308292b2 drm/i915: convert vlv_dpio_read()/write() from pipe to phy
-:360: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#360: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.c:953:
+   vlv_dpio_write(dev_priv, phy, CHV_TX_DW14(ch, i),
data << DPIO_UPAR_SHIFT);

-:435: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#435: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.c:1062:
+   vlv_dpio_write(dev_priv, phy, VLV_TX_DW2(port),
 uniqtranscale_reg_value);

-:464: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#464: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.c:1088:
+   vlv_dpio_write(dev_priv, phy, VLV_PCS_DW0(port),
 DPIO_PCS_TX_LANE2_RESET |

-:468: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#468: FILE: drivers/gpu/drm/i915/display/intel_dpio_phy.c:1091:
+   vlv_dpio_write(dev_priv, phy, VLV_PCS_DW1(port),
 DPIO_PCS_CLK_CRI_RXEB_EIOS_EN |

-:668: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#668: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1899:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW10(pipe),
 0x009f0003);

-:672: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#672: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1902:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW10(pipe),
 0x00df);

-:679: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#679: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1908:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW5(pipe),
 0x0df4);

-:683: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#683: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1911:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW5(pipe),
 0x0df7);

-:689: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#689: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1916:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW5(pipe),
 0x0df7);

-:693: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#693: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1919:
+   vlv_dpio_write(dev_priv, phy, VLV_PLL_DW5(pipe),
 0x0df4);

-:723: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#723: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:1997:
+   vlv_dpio_write(dev_priv, phy, CHV_CMN_DW13(port),
5 << DPIO_CHV_S1_DIV_SHIFT |

-:735: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#735: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:2007:
+   vlv_dpio_write(dev_priv, phy, CHV_PLL_DW1(port),
DPIO_CHV_M1_DIV_BY_2 |

-:783: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#783: FILE: drivers/gpu/drm/i915/display/intel_dpll.c:2062:
+   vlv_dpio_write(dev_priv, phy, CHV_CMN_DW14(port),
+   vlv_dpio_read(dev_priv, phy, CHV_CMN_DW14(port)) |

total: 0 errors, 0 warnings, 13 checks, 807 lines checked
8daa52e08371 drm/i915: move sideband regs to vlv_sideband_reg.h

Re: [Intel-gfx] [PATCH] drm/i915: Fix fractional bpp handling in intel_link_bw_reduce_bpp()

2023-11-14 Thread Nautiyal, Ankit K


On 11/14/2023 7:40 PM, Imre Deak wrote:

Convert crtc_state->pipe_bpp to U6.4 format as expected by the rest of
the function.

Fixes: 59a266f068b4 ("drm/i915/display: Store compressed bpp in U6.4 format")
Cc: Ankit Nautiyal 
Cc: Suraj Kandpal 
Cc: Sui Jingfeng 
Signed-off-by: Imre Deak 
---
  drivers/gpu/drm/i915/display/intel_link_bw.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c 
b/drivers/gpu/drm/i915/display/intel_link_bw.c
index 02a0af2aa5bae..9c6d35a405a18 100644
--- a/drivers/gpu/drm/i915/display/intel_link_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
@@ -55,11 +55,11 @@ int intel_link_bw_reduce_bpp(struct intel_atomic_state 
*state,
struct drm_i915_private *i915 = to_i915(state->base.dev);
enum pipe max_bpp_pipe = INVALID_PIPE;
struct intel_crtc *crtc;
-   int max_bpp = 0;
+   int max_bpp_x16 = 0;
  
  	for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {

struct intel_crtc_state *crtc_state;
-   int link_bpp;
+   int link_bpp_x16;
  
  		if (limits->bpp_limit_reached_pipes & BIT(crtc->pipe))

continue;
@@ -70,7 +70,7 @@ int intel_link_bw_reduce_bpp(struct intel_atomic_state *state,
return PTR_ERR(crtc_state);
  
  		if (crtc_state->dsc.compression_enable)

-   link_bpp = crtc_state->dsc.compressed_bpp_x16;
+   link_bpp_x16 = crtc_state->dsc.compressed_bpp_x16;



My apologies, I think, messed this up while rebasing :(

Thanks for catching this.

The change looks good to me.

Reviewed-by: Ankit Nautiyal 


Regards,

Ankit



else
/*
 * TODO: for YUV420 the actual link bpp is only half
@@ -78,10 +78,10 @@ int intel_link_bw_reduce_bpp(struct intel_atomic_state 
*state,
 * is based on the pipe bpp value, set the actual link 
bpp
 * limit here once the MST BW allocation is fixed.
 */
-   link_bpp = crtc_state->pipe_bpp;
+   link_bpp_x16 = to_bpp_x16(crtc_state->pipe_bpp);
  
-		if (link_bpp > max_bpp) {

-   max_bpp = link_bpp;
+   if (link_bpp_x16 > max_bpp_x16) {
+   max_bpp_x16 = link_bpp_x16;
max_bpp_pipe = crtc->pipe;
}
}
@@ -89,7 +89,7 @@ int intel_link_bw_reduce_bpp(struct intel_atomic_state *state,
if (max_bpp_pipe == INVALID_PIPE)
return -ENOSPC;
  
-	limits->max_bpp_x16[max_bpp_pipe] = to_bpp_x16(max_bpp) - 1;

+   limits->max_bpp_x16[max_bpp_pipe] = max_bpp_x16 - 1;
  
  	return intel_modeset_pipes_in_mask_early(state, reason,

 BIT(max_bpp_pipe));

Re: [Intel-gfx] [char-misc-next 3/4] mei: pxp: re-enable client on errors

2023-11-14 Thread Teres Alexis, Alan Previn

On Tue, 2023-11-14 at 16:00 +0200, Ville Syrjälä wrote:
> On Wed, Oct 11, 2023 at 02:01:56PM +0300, Tomas Winkler wrote:
> > From: Alexander Usyskin 
> > 
> > Disable and enable mei-pxp client on errors to clean the internal state.
> 
> This broke i915 on my Alderlake-P laptop.
> 

Hi Alex, i just relooked at the series that got merged, and i noticed
that in patch #3 of the series, you had changed mei_pxp_send_message
to return bytes sent instead of zero on success. IIRC, we had
agreed to not effect the behavior of this component interface (other
than adding the timeout) - this was the intention of Patch #4 that i
was pushing for in order to spec the interface (which continues
to say zero on success). We should fix this to stay with the original
behavior - where mei-pxp should NOT send partial packets and
will only return zero in success case where success is sending of
the complete packets - so we don't need to get back the "bytes sent"
from mei_pxp_send_message. So i think this might be causing the problem.

Side note  to Ville:, are you enabling PXP kernel config by default in
all MESA contexts? I recall that MESA folks were running some CI testing
with enable pxp contexts, but didn't realize this is being enabled by
default in all contexts. Please be aware that enabling pxp-contexts
would temporarily disabled runtime-pm during that contexts lifetime.
Also pxp contexts will be forced to be irrecoverable if it ever hangs.
The former is a hardware architecture requirement but doesn't do anything
if you're enabling display (which I beleive also blocks in ADL). The
latter was a requirement to comply with Vulkan.

...alan

[Intel-gfx] [PATCH v2] drm/edid/firmware: drop drm_kms_helper.edid_firmware backward compat

2023-11-14 Thread Jani Nikula

Since the edid_firmware module parameter was moved from
drm_kms_helper.ko to drm.ko in v4.15, we've had a backwards
compatibility helper in place, with a DRM_NOTE() suggesting to migrate
to drm.edid_firmware. This was added in commit ac6c35a4d8c7 ("drm: add
backwards compatibility support for drm_kms_helper.edid_firmware").

More than five years and 30+ kernel releases later, drop the backward
compatibility.

v2: Drop the warnings too

Acked-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid_load.c | 16 -
 drivers/gpu/drm/drm_kms_helper_common.c | 32 -
 include/drm/drm_edid.h  |  5 
 3 files changed, 53 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 5d9ef267ebb3..60fcb80bce61 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -23,22 +23,6 @@ module_param_string(edid_firmware, edid_firmware, 
sizeof(edid_firmware), 0644);
 MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID blob 
"
"from built-in data or /lib/firmware instead. ");
 
-/* Use only for backward compatibility with drm_kms_helper.edid_firmware */
-int __drm_set_edid_firmware_path(const char *path)
-{
-   scnprintf(edid_firmware, sizeof(edid_firmware), "%s", path);
-
-   return 0;
-}
-EXPORT_SYMBOL(__drm_set_edid_firmware_path);
-
-/* Use only for backward compatibility with drm_kms_helper.edid_firmware */
-int __drm_get_edid_firmware_path(char *buf, size_t bufsize)
-{
-   return scnprintf(buf, bufsize, "%s", edid_firmware);
-}
-EXPORT_SYMBOL(__drm_get_edid_firmware_path);
-
 #define GENERIC_EDIDS 6
 static const char * const generic_edid_name[GENERIC_EDIDS] = {
"edid/800x600.bin",
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c 
b/drivers/gpu/drm/drm_kms_helper_common.c
index 0bf0fc1abf54..0c7550c0462b 100644
--- a/drivers/gpu/drm/drm_kms_helper_common.c
+++ b/drivers/gpu/drm/drm_kms_helper_common.c
@@ -27,38 +27,6 @@
 
 #include 
 
-#include 
-#include 
-
-#include "drm_crtc_helper_internal.h"
-
 MODULE_AUTHOR("David Airlie, Jesse Barnes");
 MODULE_DESCRIPTION("DRM KMS helper");
 MODULE_LICENSE("GPL and additional rights");
-
-#if IS_ENABLED(CONFIG_DRM_LOAD_EDID_FIRMWARE)
-
-/* Backward compatibility for drm_kms_helper.edid_firmware */
-static int edid_firmware_set(const char *val, const struct kernel_param *kp)
-{
-   DRM_NOTE("drm_kms_helper.edid_firmware is deprecated, please use 
drm.edid_firmware instead.\n");
-
-   return __drm_set_edid_firmware_path(val);
-}
-
-static int edid_firmware_get(char *buffer, const struct kernel_param *kp)
-{
-   return __drm_get_edid_firmware_path(buffer, PAGE_SIZE);
-}
-
-static const struct kernel_param_ops edid_firmware_ops = {
-   .set = edid_firmware_set,
-   .get = edid_firmware_get,
-};
-
-module_param_cb(edid_firmware, _firmware_ops, NULL, 0644);
-__MODULE_PARM_TYPE(edid_firmware, "charp");
-MODULE_PARM_DESC(edid_firmware,
-"DEPRECATED. Use drm.edid_firmware module parameter instead.");
-
-#endif
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index e98aa6818700..518d1b8106c7 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -329,11 +329,6 @@ int drm_edid_to_speaker_allocation(const struct edid 
*edid, u8 **sadb);
 int drm_av_sync_delay(struct drm_connector *connector,
  const struct drm_display_mode *mode);
 
-#ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
-int __drm_set_edid_firmware_path(const char *path);
-int __drm_get_edid_firmware_path(char *buf, size_t bufsize);
-#endif
-
 bool drm_edid_are_equal(const struct edid *edid1, const struct edid *edid2);
 
 int
-- 
2.39.2

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Takashi Iwai

On Tue, 14 Nov 2023 12:06:45 +0100,
Ville Syrjälä wrote:
> 
> On Mon, Oct 02, 2023 at 09:38:44PM +0200, maarten.lankho...@linux.intel.com 
> wrote:
> > From: Maarten Lankhorst 
> > 
> > Now that we can use -EPROBE_DEFER, it's no longer required to spin off
> > the snd_hdac_i915_init into a workqueue.
> > 
> > Use the -EPROBE_DEFER mechanism instead, which must be returned in the
> > probe function.
> 
> This completely broke i915 audio!
> 
> I also can't see any trace of this stuff ever being posted to 
> intel-gfx so it never went through the CI.
> 
> Please fix or revert ASAP.

It's hard to judge without any log nor h/w details (as a typical bug
report from a developer :)

As a blind shot, does the patch below fix your case?


thanks,

Takashi

-- 8< --
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2141,6 +2141,9 @@ static int azx_probe(struct pci_dev *pci,
if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
err = snd_hdac_i915_init(azx_bus(chip));
if (err < 0) {
+   if (err == -EPROBE_DEFER)
+   goto out_free;
+
/* if the controller is bound only with HDMI/DP
 * (for HSW and BDW), we need to abort the probe;
 * for other chips, still continue probing as other

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Maarten Lankhorst


Hey,

Den 2023-11-14 kl. 14:39, skrev Ville Syrjälä:

On Tue, Nov 14, 2023 at 02:35:10PM +0200, Jani Nikula wrote:

On Tue, 14 Nov 2023, Ville Syrjälä  wrote:

On Mon, Oct 02, 2023 at 09:38:44PM +0200,maarten.lankho...@linux.intel.com  
wrote:

From: Maarten Lankhorst

Now that we can use -EPROBE_DEFER, it's no longer required to spin off
the snd_hdac_i915_init into a workqueue.

Use the -EPROBE_DEFER mechanism instead, which must be returned in the
probe function.

This completely broke i915 audio!

I also can't see any trace of this stuff ever being posted to
intel-gfx so it never went through the CI.

Please fix or revert ASAP.

Cc: Jani, Suresh

Ville, please file a bug at gitlab so we can track this, thanks.

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


Looks like a simple patch should be enough, can you test below?



diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 058f6e6491f9a..946aaa487f200 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2145,7 +2145,8 @@ static int azx_probe(struct pci_dev *pci,
 * for other chips, still continue probing as other
 * codecs can be on the same link.
 */
-   if (HDA_CONTROLLER_IN_GPU(pci)) {
+   if (HDA_CONTROLLER_IN_GPU(pci) ||
+   err == -EPROBE_DEFER) {
goto out_free;
} else {
/* don't bother any longer */

[Intel-gfx] [PATCH] drm/i915: Also check for VGA converter in eDP probe

2023-11-14 Thread Ville Syrjala

From: Ville Syrjälä 

Unfortunately even the HPD based detection added in
commit cfe5bdfb27fa ("drm/i915: Check HPD live state during eDP probe")
fails to detect that the VBT's eDP/DDI-A is a ghost on
Asus B360M-A (CFL+CNP). On that board eDP/DDI-A has its HPD
asserted despite nothing being actually connected there :(
The straps/fuses also indicate that the eDP port is present.

So if one boots with a VGA monitor connected the eDP probe will
mistake the DP->VGA converter hooked to DDI-E for an eDP panel
on DDI-A.

As a last resort check what kind of DP device we've detected,
and if it looks like a DP->VGA converter then conclude that
the eDP port should be ignored.

Cc: sta...@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9636
Fixes: cfe5bdfb27fa ("drm/i915: Check HPD live state during eDP probe")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 28 +++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 54bd0bffa9f0..14ee05fabd05 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6277,8 +6277,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 * (eg. Acer Chromebook C710), so we'll check it only if multiple
 * ports are attempting to use the same AUX CH, according to VBT.
 */
-   if (intel_bios_dp_has_shared_aux_ch(encoder->devdata) &&
-   !intel_digital_port_connected(encoder)) {
+   if (intel_bios_dp_has_shared_aux_ch(encoder->devdata)) {
/*
 * If this fails, presume the DPCD answer came
 * from some other port using the same AUX CH.
@@ -6286,10 +6285,27 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
 * FIXME maybe cleaner to check this before the
 * DPCD read? Would need sort out the VDD handling...
 */
-   drm_info(_priv->drm,
-"[ENCODER:%d:%s] HPD is down, disabling eDP\n",
-encoder->base.base.id, encoder->base.name);
-   goto out_vdd_off;
+   if (!intel_digital_port_connected(encoder)) {
+   drm_info(_priv->drm,
+"[ENCODER:%d:%s] HPD is down, disabling eDP\n",
+encoder->base.base.id, encoder->base.name);
+   goto out_vdd_off;
+   }
+
+   /*
+* Unfortunately even the HPD based detection fails on
+* eg. Asus B360M-A (CFL+CNP), so as a last resort fall
+* back to checking for a VGA branch device. Only do this
+* on known affected platforms to minimize false positives.
+*/
+   if (DISPLAY_VER(dev_priv) == 9 && 
drm_dp_is_branch(intel_dp->dpcd) &&
+   (intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
DP_DWN_STRM_PORT_TYPE_MASK) ==
+   DP_DWN_STRM_PORT_TYPE_ANALOG) {
+   drm_info(_priv->drm,
+"[ENCODER:%d:%s] VGA converter detected, 
disabling eDP\n",
+encoder->base.base.id, encoder->base.name);
+   goto out_vdd_off;
+   }
}
 
mutex_lock(_priv->drm.mode_config.mutex);
-- 
2.41.0

[Intel-gfx] [PATCH] drm/i915: Fix fractional bpp handling in intel_link_bw_reduce_bpp()

2023-11-14 Thread Imre Deak

Convert crtc_state->pipe_bpp to U6.4 format as expected by the rest of
the function.

Fixes: 59a266f068b4 ("drm/i915/display: Store compressed bpp in U6.4 format")
Cc: Ankit Nautiyal 
Cc: Suraj Kandpal 
Cc: Sui Jingfeng 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/display/intel_link_bw.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c 
b/drivers/gpu/drm/i915/display/intel_link_bw.c
index 02a0af2aa5bae..9c6d35a405a18 100644
--- a/drivers/gpu/drm/i915/display/intel_link_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
@@ -55,11 +55,11 @@ int intel_link_bw_reduce_bpp(struct intel_atomic_state 
*state,
struct drm_i915_private *i915 = to_i915(state->base.dev);
enum pipe max_bpp_pipe = INVALID_PIPE;
struct intel_crtc *crtc;
-   int max_bpp = 0;
+   int max_bpp_x16 = 0;
 
for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
struct intel_crtc_state *crtc_state;
-   int link_bpp;
+   int link_bpp_x16;
 
if (limits->bpp_limit_reached_pipes & BIT(crtc->pipe))
continue;
@@ -70,7 +70,7 @@ int intel_link_bw_reduce_bpp(struct intel_atomic_state *state,
return PTR_ERR(crtc_state);
 
if (crtc_state->dsc.compression_enable)
-   link_bpp = crtc_state->dsc.compressed_bpp_x16;
+   link_bpp_x16 = crtc_state->dsc.compressed_bpp_x16;
else
/*
 * TODO: for YUV420 the actual link bpp is only half
@@ -78,10 +78,10 @@ int intel_link_bw_reduce_bpp(struct intel_atomic_state 
*state,
 * is based on the pipe bpp value, set the actual link 
bpp
 * limit here once the MST BW allocation is fixed.
 */
-   link_bpp = crtc_state->pipe_bpp;
+   link_bpp_x16 = to_bpp_x16(crtc_state->pipe_bpp);
 
-   if (link_bpp > max_bpp) {
-   max_bpp = link_bpp;
+   if (link_bpp_x16 > max_bpp_x16) {
+   max_bpp_x16 = link_bpp_x16;
max_bpp_pipe = crtc->pipe;
}
}
@@ -89,7 +89,7 @@ int intel_link_bw_reduce_bpp(struct intel_atomic_state *state,
if (max_bpp_pipe == INVALID_PIPE)
return -ENOSPC;
 
-   limits->max_bpp_x16[max_bpp_pipe] = to_bpp_x16(max_bpp) - 1;
+   limits->max_bpp_x16[max_bpp_pipe] = max_bpp_x16 - 1;
 
return intel_modeset_pipes_in_mask_early(state, reason,
 BIT(max_bpp_pipe));
-- 
2.39.2

Re: [Intel-gfx] [char-misc-next 3/4] mei: pxp: re-enable client on errors

2023-11-14 Thread Ville Syrjälä

On Wed, Oct 11, 2023 at 02:01:56PM +0300, Tomas Winkler wrote:
> From: Alexander Usyskin 
> 
> Disable and enable mei-pxp client on errors to clean the internal state.

This broke i915 on my Alderlake-P laptop.

Trying to start Xorg just hangs and I eventually have to power off the
laptop to get things back into shape.

The behaviour gets a bit better after commit fb99e79ee62a ("mei: update 
mei-pxp's
component interface with timeouts") as Xorg "only" gets blocked for
~10 seconds, after which it manages to start, and I get a bunch of spew
in dmesg:
[   25.431535] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   30.435241] mei_pxp :00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: 
Trying to reset the channel...
[   30.435965] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   30.437341] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   30.437356] i915 :00:02.0: [drm] *ERROR* Failed to send tee msg for 
inv-stream-key-15, ret=[28]
[   35.555210] mei_pxp :00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: 
Trying to reset the channel...
[   35.555919] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   35.555937] i915 :00:02.0: [drm] *ERROR* Failed to send tee msg init arb 
session, ret=[-62]
[   35.555941] i915 :00:02.0: [drm] *ERROR* tee cmd for arb session 
creation failed
[   35.556765] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   36.021808] fuse: init (API version 7.39)
[   40.675183] mei_pxp :00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: 
Trying to reset the channel...
[   40.676045] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   40.676591] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   40.676602] i915 :00:02.0: [drm] *ERROR* Failed to send tee msg for 
inv-stream-key-15, ret=[28]
[   40.960209] mate-session-ch[5936]: memfd_create() called without MFD_EXEC or 
MFD_NOEXEC_SEAL set
[   45.795172] mei_pxp :00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: 
Trying to reset the channel...
[   45.795872] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   45.796520] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   50.915183] mei_pxp :00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: 
Trying to reset the channel...
[   50.916005] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   50.916012] i915 :00:02.0: [drm] *ERROR* Failed to send tee msg for 
inv-stream-key-15, ret=[-62]
[   50.916846] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   56.035149] mei_pxp :00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: 
Trying to reset the channel...
[   56.035956] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   56.036585] i915 :00:02.0: [drm] *ERROR* Failed to send PXP TEE message
[   56.036592] i915 :00:02.0: [drm] *ERROR* Failed to send tee msg for 
inv-stream-key-15, ret=[28]
[   61.155137] mei_pxp :00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: 
Trying to reset the channel...

The same spew repeats every time I run any application that uses the GPU,
and the application also gets blocked for a long time (eg. firefox takes
over 15 seconds to start now).

> 
> Signed-off-by: Alexander Usyskin 
> Signed-off-by: Tomas Winkler 
> ---
>  drivers/misc/mei/pxp/mei_pxp.c | 70 +++---
>  1 file changed, 48 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/misc/mei/pxp/mei_pxp.c b/drivers/misc/mei/pxp/mei_pxp.c
> index c6cdd6a47308ebcc72f34c38..9875d16445bb03efcfb31cd9 100644
> --- a/drivers/misc/mei/pxp/mei_pxp.c
> +++ b/drivers/misc/mei/pxp/mei_pxp.c
> @@ -23,6 +23,24 @@
>  
>  #include "mei_pxp.h"
>  
> +static inline int mei_pxp_reenable(const struct device *dev, struct 
> mei_cl_device *cldev)
> +{
> + int ret;
> +
> + dev_warn(dev, "Trying to reset the channel...\n");
> + ret = mei_cldev_disable(cldev);
> + if (ret < 0)
> + dev_warn(dev, "mei_cldev_disable failed. %d\n", ret);
> + /*
> +  * Explicitly ignoring disable failure,
> +  * enable may fix the states and succeed
> +  */
> + ret = mei_cldev_enable(cldev);
> + if (ret < 0)
> + dev_err(dev, "mei_cldev_enable failed. %d\n", ret);
> + return ret;
> +}
> +
>  /**
>   * mei_pxp_send_message() - Sends a PXP message to ME FW.
>   * @dev: device corresponding to the mei_cl_device
> @@ -35,6 +53,7 @@ mei_pxp_send_message(struct device *dev, const void 
> *message, size_t size)
>  {
>   struct mei_cl_device *cldev;
>   ssize_t byte;
> + int ret;
>  
>   if (!dev || !message)
>   return -EINVAL;
> @@ -44,10 +63,20 @@ mei_pxp_send_message(struct device *dev, const void 
> *message, size_t size)
>   byte = mei_cldev_send(cldev, message, size);
>   if (byte < 0) {
>   dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> - return byte;
> + switch (byte)

Re: [Intel-gfx] [PATCH] drm/i915/display: Remove dead code around intel_atomic_helper->free_list

2023-11-14 Thread Hogander, Jouni

On Tue, 2023-11-14 at 10:48 +0200, Ville Syrjälä wrote:
> On Fri, Nov 10, 2023 at 10:24:55AM +0200, Jouni Högander wrote:
> > After switching to directly using dma_fence instead of
> > i915_sw_fence we
> > have left some dead code around intel_atomic_helper->free_list.
> > Remove that
> > dead code.
> > 
> > Signed-off-by: Jouni Högander 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c  | 20 ---
> > 
> >  .../gpu/drm/i915/display/intel_display_core.h |  6 --
> >  .../drm/i915/display/intel_display_driver.c   |  7 ---
> >  3 files changed, 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 3effafcbb411..387acf21b794 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -7086,24 +7086,6 @@ static void
> > skl_commit_modeset_enables(struct intel_atomic_state *state)
> > drm_WARN_ON(_priv->drm, update_pipes);
> >  }
> >  
> > -static void intel_atomic_helper_free_state(struct drm_i915_private
> > *dev_priv)
> > -{
> > -   struct intel_atomic_state *state, *next;
> > -   struct llist_node *freed;
> > -
> > -   freed = llist_del_all(_priv-
> > >display.atomic_helper.free_list);
> > -   llist_for_each_entry_safe(state, next, freed, freed)
> 
> state.freed is also dead.

Thank you for pointing this out. Please check version 2. of my patch
which is addressing this one as well.

BR,

Jouni Högander

>

[Intel-gfx] [PATCH v2] drm/i915/display: Remove dead code around intel_atomic_helper->free_list

2023-11-14 Thread Jouni Högander

After switching to directly using dma_fence instead of i915_sw_fence we
have left some dead code around intel_atomic_helper->free_list. Remove that
dead code.

v2: Remove intel_atomic_state->freed as well

Signed-off-by: Jouni Högander 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 20 ---
 .../gpu/drm/i915/display/intel_display_core.h |  6 --
 .../drm/i915/display/intel_display_driver.c   |  7 ---
 .../drm/i915/display/intel_display_types.h|  2 --
 4 files changed, 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 3effafcbb411..387acf21b794 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7086,24 +7086,6 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
drm_WARN_ON(_priv->drm, update_pipes);
 }
 
-static void intel_atomic_helper_free_state(struct drm_i915_private *dev_priv)
-{
-   struct intel_atomic_state *state, *next;
-   struct llist_node *freed;
-
-   freed = llist_del_all(_priv->display.atomic_helper.free_list);
-   llist_for_each_entry_safe(state, next, freed, freed)
-   drm_atomic_state_put(>base);
-}
-
-void intel_atomic_helper_free_state_worker(struct work_struct *work)
-{
-   struct drm_i915_private *dev_priv =
-   container_of(work, typeof(*dev_priv), 
display.atomic_helper.free_work);
-
-   intel_atomic_helper_free_state(dev_priv);
-}
-
 static void intel_atomic_commit_fence_wait(struct intel_atomic_state 
*intel_state)
 {
struct drm_i915_private *i915 = to_i915(intel_state->base.dev);
@@ -7139,8 +7121,6 @@ static void intel_atomic_cleanup_work(struct work_struct 
*work)
drm_atomic_helper_cleanup_planes(>drm, >base);
drm_atomic_helper_commit_cleanup_done(>base);
drm_atomic_state_put(>base);
-
-   intel_atomic_helper_free_state(i915);
 }
 
 static void intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state 
*state)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h 
b/drivers/gpu/drm/i915/display/intel_display_core.h
index aa8be02c9e54..34945f733a97 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -298,12 +298,6 @@ struct intel_display {
const struct intel_audio_funcs *audio;
} funcs;
 
-   /* Grouping using anonymous structs. Keep sorted. */
-   struct intel_atomic_helper {
-   struct llist_head free_list;
-   struct work_struct free_work;
-   } atomic_helper;
-
struct {
/* backlight registers and fields in struct intel_panel */
struct mutex lock;
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c 
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 62f7b10484be..9df9097a0255 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -259,10 +259,6 @@ int intel_display_driver_probe_noirq(struct 
drm_i915_private *i915)
if (ret)
goto cleanup_vga_client_pw_domain_dmc;
 
-   init_llist_head(>display.atomic_helper.free_list);
-   INIT_WORK(>display.atomic_helper.free_work,
- intel_atomic_helper_free_state_worker);
-
intel_init_quirks(i915);
 
intel_fbc_init(i915);
@@ -430,9 +426,6 @@ void intel_display_driver_remove(struct drm_i915_private 
*i915)
flush_workqueue(i915->display.wq.flip);
flush_workqueue(i915->display.wq.modeset);
 
-   flush_work(>display.atomic_helper.free_work);
-   drm_WARN_ON(>drm, 
!llist_empty(>display.atomic_helper.free_list));
-
/*
 * MST topology needs to be suspended so we don't have any calls to
 * fbdev after it's finalized. MST will be destroyed later as part of
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 926bf9c1a3ed..8ddfc6efef96 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -678,8 +678,6 @@ struct intel_atomic_state {
bool skip_intermediate_wm;
 
bool rps_interactive;
-
-   struct llist_node freed;
 };
 
 struct intel_plane_state {
-- 
2.34.1

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Ville Syrjälä

On Tue, Nov 14, 2023 at 02:35:10PM +0200, Jani Nikula wrote:
> On Tue, 14 Nov 2023, Ville Syrjälä  wrote:
> > On Mon, Oct 02, 2023 at 09:38:44PM +0200, maarten.lankho...@linux.intel.com 
> > wrote:
> >> From: Maarten Lankhorst 
> >> 
> >> Now that we can use -EPROBE_DEFER, it's no longer required to spin off
> >> the snd_hdac_i915_init into a workqueue.
> >> 
> >> Use the -EPROBE_DEFER mechanism instead, which must be returned in the
> >> probe function.
> >
> > This completely broke i915 audio!
> >
> > I also can't see any trace of this stuff ever being posted to 
> > intel-gfx so it never went through the CI.
> >
> > Please fix or revert ASAP.
> 
> Cc: Jani, Suresh
> 
> Ville, please file a bug at gitlab so we can track this, thanks.

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

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Saarinen, Jani

Hi, 
> -Original Message-
> From: Maarten Lankhorst 
> Sent: Tuesday, November 14, 2023 3:30 PM
> To: Jani Nikula ; Ville Syrjälä
> 
> Cc: Takashi Iwai ; intel-gfx@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; alsa-de...@alsa-project.org; Saarinen, Jani
> ; Kurmi, Suresh Kumar
> 
> Subject: Re: [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init
> to before probe_work.
> 
> Hey,
> 
> Den 2023-11-14 kl. 13:35, skrev Jani Nikula:
> > On Tue, 14 Nov 2023, Ville Syrjälä  wrote:
> >> On Mon, Oct 02, 2023 at 09:38:44PM +0200,
> maarten.lankho...@linux.intel.com wrote:
> >>> From: Maarten Lankhorst 
> >>>
> >>> Now that we can use -EPROBE_DEFER, it's no longer required to spin
> >>> off the snd_hdac_i915_init into a workqueue.
> >>>
> >>> Use the -EPROBE_DEFER mechanism instead, which must be returned in
> >>> the probe function.
> >> This completely broke i915 audio!
> >>
> >> I also can't see any trace of this stuff ever being posted to
> >> intel-gfx so it never went through the CI.
> >>
> >> Please fix or revert ASAP.
> > Cc: Jani, Suresh
> >
> > Ville, please file a bug at gitlab so we can track this, thanks.
> 
> I've originally tested this on TGL and DG2, so can you be more specific on 
> what
> broke?
Was this series tested on CI  ever as Ville saying no? How this got merged? 

> 
> Cheers,
> 
> ~Maarten
> 
> >>> Signed-off-by: Maarten Lankhorst 
> >>> Reviewed-by: Kai Vehmanen 
> >>> Reviewed-by: Pierre-Louis Bossart
> >>> 
> >>> Signed-off-by: Maarten Lankhorst 
> >>> ---
> >>>   sound/pci/hda/hda_intel.c | 54 +++
> >>>   1 file changed, 27 insertions(+), 27 deletions(-)
> >>>
> >>> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> >>> index e42ad0e816e1..9dad3607596a 100644
> >>> --- a/sound/pci/hda/hda_intel.c
> >>> +++ b/sound/pci/hda/hda_intel.c
> >>> @@ -2135,6 +2135,33 @@ static int azx_probe(struct pci_dev *pci,
> >>>
> >>>   pci_set_drvdata(pci, card);
> >>>
> >>> +#ifdef CONFIG_SND_HDA_I915
> >>> + /* bind with i915 if needed */
> >>> + if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
> >>> + err = snd_hdac_i915_init(azx_bus(chip), false);
> >>> + if (err < 0) {
> >>> + /* if the controller is bound only with HDMI/DP
> >>> +  * (for HSW and BDW), we need to abort the probe;
> >>> +  * for other chips, still continue probing as other
> >>> +  * codecs can be on the same link.
> >>> +  */
> >>> + if (HDA_CONTROLLER_IN_GPU(pci)) {
> >>> + goto out_free;
> >>> + } else {
> >>> + /* don't bother any longer */
> >>> + chip->driver_caps &=
> ~AZX_DCAPS_I915_COMPONENT;
> >>> + }
> >>> + }
> >>> +
> >>> + /* HSW/BDW controllers need this power */
> >>> + if (HDA_CONTROLLER_IN_GPU(pci))
> >>> + hda->need_i915_power = true;
> >>> + }
> >>> +#else
> >>> + if (HDA_CONTROLLER_IN_GPU(pci))
> >>> + dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in
> >>> +CONFIG_SND_HDA_I915\n"); #endif
> >>> +
> >>>   err = register_vga_switcheroo(chip);
> >>>   if (err < 0) {
> >>>   dev_err(card->dev, "Error registering vga_switcheroo 
> >>> client\n");
> >>> @@ -2162,11 +2189,6 @@ static int azx_probe(struct pci_dev *pci,
> >>>   }
> >>>   #endif /* CONFIG_SND_HDA_PATCH_LOADER */
> >>>
> >>> -#ifndef CONFIG_SND_HDA_I915
> >>> - if (HDA_CONTROLLER_IN_GPU(pci))
> >>> - dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in
> CONFIG_SND_HDA_I915\n");
> >>> -#endif
> >>> -
> >>>   if (schedule_probe)
> >>>   schedule_delayed_work(>probe_work, 0);
> >>>
> >>> @@ -2264,28 +2286,6 @@ static int azx_probe_continue(struct azx *chip)
> >>>   to_hda_bus(bus)->bus_probing = 1;
> >>>   hda->probe_continued = 1;
> >>>
> >>> - /* bind with i915 if needed */
> >>> - if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
> >>> - err = snd_hdac_i915_init(bus, true);
> >>> - if (err < 0) {
> >>> - /* if the controller is bound only with HDMI/DP
> >>> -  * (for HSW and BDW), we need to abort the probe;
> >>> -  * for other chips, still continue probing as other
> >>> -  * codecs can be on the same link.
> >>> -  */
> >>> - if (HDA_CONTROLLER_IN_GPU(pci)) {
> >>> - goto out_free;
> >>> - } else {
> >>> - /* don't bother any longer */
> >>> - chip->driver_caps &=
> ~AZX_DCAPS_I915_COMPONENT;
> >>> - }
> >>> - }
> >>> -
> >>> - /* HSW/BDW controllers need this power */
> >>> - if (HDA_CONTROLLER_IN_GPU(pci))
> >>> - hda->need_i915_power

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Maarten Lankhorst


Hey,

Den 2023-11-14 kl. 13:35, skrev Jani Nikula:

On Tue, 14 Nov 2023, Ville Syrjälä  wrote:

On Mon, Oct 02, 2023 at 09:38:44PM +0200, maarten.lankho...@linux.intel.com 
wrote:

From: Maarten Lankhorst 

Now that we can use -EPROBE_DEFER, it's no longer required to spin off
the snd_hdac_i915_init into a workqueue.

Use the -EPROBE_DEFER mechanism instead, which must be returned in the
probe function.

This completely broke i915 audio!

I also can't see any trace of this stuff ever being posted to
intel-gfx so it never went through the CI.

Please fix or revert ASAP.

Cc: Jani, Suresh

Ville, please file a bug at gitlab so we can track this, thanks.


I've originally tested this on TGL and DG2, so can you be more specific 
on what broke?


Cheers,

~Maarten


Signed-off-by: Maarten Lankhorst 
Reviewed-by: Kai Vehmanen 
Reviewed-by: Pierre-Louis Bossart 
Signed-off-by: Maarten Lankhorst 
---
  sound/pci/hda/hda_intel.c | 54 +++
  1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index e42ad0e816e1..9dad3607596a 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2135,6 +2135,33 @@ static int azx_probe(struct pci_dev *pci,
  
  	pci_set_drvdata(pci, card);
  
+#ifdef CONFIG_SND_HDA_I915

+   /* bind with i915 if needed */
+   if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
+   err = snd_hdac_i915_init(azx_bus(chip), false);
+   if (err < 0) {
+   /* if the controller is bound only with HDMI/DP
+* (for HSW and BDW), we need to abort the probe;
+* for other chips, still continue probing as other
+* codecs can be on the same link.
+*/
+   if (HDA_CONTROLLER_IN_GPU(pci)) {
+   goto out_free;
+   } else {
+   /* don't bother any longer */
+   chip->driver_caps &= ~AZX_DCAPS_I915_COMPONENT;
+   }
+   }
+
+   /* HSW/BDW controllers need this power */
+   if (HDA_CONTROLLER_IN_GPU(pci))
+   hda->need_i915_power = true;
+   }
+#else
+   if (HDA_CONTROLLER_IN_GPU(pci))
+   dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in 
CONFIG_SND_HDA_I915\n");
+#endif
+
err = register_vga_switcheroo(chip);
if (err < 0) {
dev_err(card->dev, "Error registering vga_switcheroo client\n");
@@ -2162,11 +2189,6 @@ static int azx_probe(struct pci_dev *pci,
}
  #endif /* CONFIG_SND_HDA_PATCH_LOADER */
  
-#ifndef CONFIG_SND_HDA_I915

-   if (HDA_CONTROLLER_IN_GPU(pci))
-   dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in 
CONFIG_SND_HDA_I915\n");
-#endif
-
if (schedule_probe)
schedule_delayed_work(>probe_work, 0);
  
@@ -2264,28 +2286,6 @@ static int azx_probe_continue(struct azx *chip)

to_hda_bus(bus)->bus_probing = 1;
hda->probe_continued = 1;
  
-	/* bind with i915 if needed */

-   if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
-   err = snd_hdac_i915_init(bus, true);
-   if (err < 0) {
-   /* if the controller is bound only with HDMI/DP
-* (for HSW and BDW), we need to abort the probe;
-* for other chips, still continue probing as other
-* codecs can be on the same link.
-*/
-   if (HDA_CONTROLLER_IN_GPU(pci)) {
-   goto out_free;
-   } else {
-   /* don't bother any longer */
-   chip->driver_caps &= ~AZX_DCAPS_I915_COMPONENT;
-   }
-   }
-
-   /* HSW/BDW controllers need this power */
-   if (HDA_CONTROLLER_IN_GPU(pci))
-   hda->need_i915_power = true;
-   }
-
/* Request display power well for the HDA controller or codec. For
 * Haswell/Broadwell, both the display HDA controller and codec need
 * this power. For other platforms, like Baytrail/Braswell, only the
--
2.40.1

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: Account for channel coding efficiency on UHBR links

2023-11-14 Thread Imre Deak

On Tue, Nov 14, 2023 at 11:00:49AM +0200, Jani Nikula wrote:
> On Mon, 13 Nov 2023, Imre Deak  wrote:
> > Apply the correct BW allocation overhead and channel coding efficiency
> > on UHBR link rates, similarly to DP1.4 link rates.
> >
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c | 10 --
> >  1 file changed, 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 3effafcbb411a..24aebdb715e7d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2398,16 +2398,6 @@ add_bw_alloc_overhead(int link_clock, int 
> > bw_overhead,
> > int ch_coding_efficiency =
> > drm_dp_bw_channel_coding_efficiency(is_uhbr);
> 
> Why do we have this and intel_dp_max_data_rate() separately?

This function calculates an m/n ratio for a given pixel/data rate,
applying both the allocation overhead (FEC, SSC, etc.) and the channel
coding efficiency. intel_dp_max_data_rate() calculates a maximum data
rate applying only the channel coding efficiency.

I think intel_dp_max_data_rate() could be simplified, so the two
functions use the same channel coding efficiency to:

DIV_ROUND_UP_ULL(mul_u32_u32(max_link_rate_kbps * max_lanes,
 drm_dp_bw_channel_coding_efficiency(is_uhbr)),
 100ULL * 8)

--Imre

> 
> BR,
> Jani.
> 
> 
> >  
> > -   /*
> > -* TODO: adjust for actual UHBR channel coding efficiency and BW
> > -* overhead.
> > -*/
> > -   if (is_uhbr) {
> > -   *data_m = pixel_data_rate;
> > -   *data_n = link_data_rate * 8 / 10;
> > -   return;
> > -   }
> > -
> > *data_m = DIV_ROUND_UP_ULL(mul_u32_u32(pixel_data_rate, bw_overhead),
> >100);
> > *data_n = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_data_rate, 
> > ch_coding_efficiency),
> 
> -- 
> Jani Nikula, Intel

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Jani Nikula

On Tue, 14 Nov 2023, Ville Syrjälä  wrote:
> On Mon, Oct 02, 2023 at 09:38:44PM +0200, maarten.lankho...@linux.intel.com 
> wrote:
>> From: Maarten Lankhorst 
>> 
>> Now that we can use -EPROBE_DEFER, it's no longer required to spin off
>> the snd_hdac_i915_init into a workqueue.
>> 
>> Use the -EPROBE_DEFER mechanism instead, which must be returned in the
>> probe function.
>
> This completely broke i915 audio!
>
> I also can't see any trace of this stuff ever being posted to 
> intel-gfx so it never went through the CI.
>
> Please fix or revert ASAP.

Cc: Jani, Suresh

Ville, please file a bug at gitlab so we can track this, thanks.

BR,
Jani.



>
>> 
>> Signed-off-by: Maarten Lankhorst 
>> Reviewed-by: Kai Vehmanen 
>> Reviewed-by: Pierre-Louis Bossart 
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  sound/pci/hda/hda_intel.c | 54 +++
>>  1 file changed, 27 insertions(+), 27 deletions(-)
>> 
>> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
>> index e42ad0e816e1..9dad3607596a 100644
>> --- a/sound/pci/hda/hda_intel.c
>> +++ b/sound/pci/hda/hda_intel.c
>> @@ -2135,6 +2135,33 @@ static int azx_probe(struct pci_dev *pci,
>>  
>>  pci_set_drvdata(pci, card);
>>  
>> +#ifdef CONFIG_SND_HDA_I915
>> +/* bind with i915 if needed */
>> +if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
>> +err = snd_hdac_i915_init(azx_bus(chip), false);
>> +if (err < 0) {
>> +/* if the controller is bound only with HDMI/DP
>> + * (for HSW and BDW), we need to abort the probe;
>> + * for other chips, still continue probing as other
>> + * codecs can be on the same link.
>> + */
>> +if (HDA_CONTROLLER_IN_GPU(pci)) {
>> +goto out_free;
>> +} else {
>> +/* don't bother any longer */
>> +chip->driver_caps &= ~AZX_DCAPS_I915_COMPONENT;
>> +}
>> +}
>> +
>> +/* HSW/BDW controllers need this power */
>> +if (HDA_CONTROLLER_IN_GPU(pci))
>> +hda->need_i915_power = true;
>> +}
>> +#else
>> +if (HDA_CONTROLLER_IN_GPU(pci))
>> +dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in 
>> CONFIG_SND_HDA_I915\n");
>> +#endif
>> +
>>  err = register_vga_switcheroo(chip);
>>  if (err < 0) {
>>  dev_err(card->dev, "Error registering vga_switcheroo client\n");
>> @@ -2162,11 +2189,6 @@ static int azx_probe(struct pci_dev *pci,
>>  }
>>  #endif /* CONFIG_SND_HDA_PATCH_LOADER */
>>  
>> -#ifndef CONFIG_SND_HDA_I915
>> -if (HDA_CONTROLLER_IN_GPU(pci))
>> -dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in 
>> CONFIG_SND_HDA_I915\n");
>> -#endif
>> -
>>  if (schedule_probe)
>>  schedule_delayed_work(>probe_work, 0);
>>  
>> @@ -2264,28 +2286,6 @@ static int azx_probe_continue(struct azx *chip)
>>  to_hda_bus(bus)->bus_probing = 1;
>>  hda->probe_continued = 1;
>>  
>> -/* bind with i915 if needed */
>> -if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
>> -err = snd_hdac_i915_init(bus, true);
>> -if (err < 0) {
>> -/* if the controller is bound only with HDMI/DP
>> - * (for HSW and BDW), we need to abort the probe;
>> - * for other chips, still continue probing as other
>> - * codecs can be on the same link.
>> - */
>> -if (HDA_CONTROLLER_IN_GPU(pci)) {
>> -goto out_free;
>> -} else {
>> -/* don't bother any longer */
>> -chip->driver_caps &= ~AZX_DCAPS_I915_COMPONENT;
>> -}
>> -}
>> -
>> -/* HSW/BDW controllers need this power */
>> -if (HDA_CONTROLLER_IN_GPU(pci))
>> -hda->need_i915_power = true;
>> -}
>> -
>>  /* Request display power well for the HDA controller or codec. For
>>   * Haswell/Broadwell, both the display HDA controller and codec need
>>   * this power. For other platforms, like Baytrail/Braswell, only the
>> -- 
>> 2.40.1

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH v6] drm/i915/dsb: DSB code refactoring

2023-11-14 Thread Coelho, Luciano

On Tue, 2023-11-14 at 11:35 +, Manna, Animesh wrote:
> 
> > -Original Message-
> > From: Coelho, Luciano 
> > Sent: Tuesday, November 14, 2023 4:47 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: Nikula, Jani 
> > Subject: Re: [Intel-gfx] [PATCH v6] drm/i915/dsb: DSB code refactoring
> > 
> > On Fri, 2023-11-10 at 08:55 +0530, Animesh Manna wrote:
> > > Refactor DSB implementation to be compatible with Xe driver.
> > > 
> > > v1: RFC version.
> > > v2: Make intel_dsb structure opaque from external usage. [Jani]
> > > v3: Rebased on latest.
> > > v4:
> > > - Add boundary check in dsb_buffer_memset(). [Luca]
> > > - Use size_t instead of u32. [Luca]
> > > v5: WARN_ON() added for out of boudary case with some optimization.
> > [Luca]
> > 
> > ...and what is different in v6?
> 
> Rebased on latest and fix a rebase-miss which CI did not caught well. Before 
> merging want the green signal from CI.

Okay, it's good to mention that.

Anyway, my r-b is still valid. ;)

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH v6] drm/i915/dsb: DSB code refactoring

2023-11-14 Thread Manna, Animesh



> -Original Message-
> From: Coelho, Luciano 
> Sent: Tuesday, November 14, 2023 4:47 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani 
> Subject: Re: [Intel-gfx] [PATCH v6] drm/i915/dsb: DSB code refactoring
> 
> On Fri, 2023-11-10 at 08:55 +0530, Animesh Manna wrote:
> > Refactor DSB implementation to be compatible with Xe driver.
> >
> > v1: RFC version.
> > v2: Make intel_dsb structure opaque from external usage. [Jani]
> > v3: Rebased on latest.
> > v4:
> > - Add boundary check in dsb_buffer_memset(). [Luca]
> > - Use size_t instead of u32. [Luca]
> > v5: WARN_ON() added for out of boudary case with some optimization.
> [Luca]
> 
> ...and what is different in v6?

Rebased on latest and fix a rebase-miss which CI did not caught well. Before 
merging want the green signal from CI.

Regards,
Animesh
> 
> --
> Cheers,
> Luca.

Re: [Intel-gfx] [PATCH v6] drm/i915/dsb: DSB code refactoring

2023-11-14 Thread Coelho, Luciano

On Fri, 2023-11-10 at 08:55 +0530, Animesh Manna wrote:
> Refactor DSB implementation to be compatible with Xe driver.
> 
> v1: RFC version.
> v2: Make intel_dsb structure opaque from external usage. [Jani]
> v3: Rebased on latest.
> v4:
> - Add boundary check in dsb_buffer_memset(). [Luca]
> - Use size_t instead of u32. [Luca]
> v5: WARN_ON() added for out of boudary case with some optimization. [Luca]

...and what is different in v6?

--
Cheers,
Luca.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsb: DSB code refactoring (rev6)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/dsb: DSB code refactoring (rev6)
URL   : https://patchwork.freedesktop.org/series/124141/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13859 -> Patchwork_124141v6


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (33 -> 33)
--

  Additional (1): fi-hsw-4770 
  Missing(1): fi-kbl-soraka 

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_selftest@live@mman:
- bat-rpls-1: [PASS][5] -> [INCOMPLETE][6] ([i915#7392])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13859/bat-rpls-1/igt@i915_selftest@l...@mman.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/bat-rpls-1/igt@i915_selftest@l...@mman.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#5190])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271]) +12 other tests 
skip
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-c-dp-5:
- bat-adlp-11:[PASS][9] -> [DMESG-FAIL][10] ([i915#6868])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13859/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-c-dp-5.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-c-dp-5.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-d-dp-5:
- bat-adlp-11:[PASS][11] -> [FAIL][12] ([i915#9666])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13859/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-d-dp-5.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/bat-adlp-11/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-d-dp-5.html

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

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1:
- fi-hsw-4770:NOTRUN -> [DMESG-WARN][14] ([i915#8841]) +6 other 
tests dmesg-warn
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/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][15] ([fdo#109271] / [i915#1072]) +3 
other tests skip
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- bat-dg2-11: [DMESG-FAIL][16] ([i915#7651]) -> [PASS][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13859/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][18] ([i915#8668]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13859/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124141v6/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#1072]:

Re: [Intel-gfx] [Intel-xe] [PATCH 11/14] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.

2023-11-14 Thread Ville Syrjälä

On Mon, Oct 02, 2023 at 09:38:44PM +0200, maarten.lankho...@linux.intel.com 
wrote:
> From: Maarten Lankhorst 
> 
> Now that we can use -EPROBE_DEFER, it's no longer required to spin off
> the snd_hdac_i915_init into a workqueue.
> 
> Use the -EPROBE_DEFER mechanism instead, which must be returned in the
> probe function.

This completely broke i915 audio!

I also can't see any trace of this stuff ever being posted to 
intel-gfx so it never went through the CI.

Please fix or revert ASAP.

> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Kai Vehmanen 
> Reviewed-by: Pierre-Louis Bossart 
> Signed-off-by: Maarten Lankhorst 
> ---
>  sound/pci/hda/hda_intel.c | 54 +++
>  1 file changed, 27 insertions(+), 27 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index e42ad0e816e1..9dad3607596a 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -2135,6 +2135,33 @@ static int azx_probe(struct pci_dev *pci,
>  
>   pci_set_drvdata(pci, card);
>  
> +#ifdef CONFIG_SND_HDA_I915
> + /* bind with i915 if needed */
> + if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
> + err = snd_hdac_i915_init(azx_bus(chip), false);
> + if (err < 0) {
> + /* if the controller is bound only with HDMI/DP
> +  * (for HSW and BDW), we need to abort the probe;
> +  * for other chips, still continue probing as other
> +  * codecs can be on the same link.
> +  */
> + if (HDA_CONTROLLER_IN_GPU(pci)) {
> + goto out_free;
> + } else {
> + /* don't bother any longer */
> + chip->driver_caps &= ~AZX_DCAPS_I915_COMPONENT;
> + }
> + }
> +
> + /* HSW/BDW controllers need this power */
> + if (HDA_CONTROLLER_IN_GPU(pci))
> + hda->need_i915_power = true;
> + }
> +#else
> + if (HDA_CONTROLLER_IN_GPU(pci))
> + dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in 
> CONFIG_SND_HDA_I915\n");
> +#endif
> +
>   err = register_vga_switcheroo(chip);
>   if (err < 0) {
>   dev_err(card->dev, "Error registering vga_switcheroo client\n");
> @@ -2162,11 +2189,6 @@ static int azx_probe(struct pci_dev *pci,
>   }
>  #endif /* CONFIG_SND_HDA_PATCH_LOADER */
>  
> -#ifndef CONFIG_SND_HDA_I915
> - if (HDA_CONTROLLER_IN_GPU(pci))
> - dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in 
> CONFIG_SND_HDA_I915\n");
> -#endif
> -
>   if (schedule_probe)
>   schedule_delayed_work(>probe_work, 0);
>  
> @@ -2264,28 +2286,6 @@ static int azx_probe_continue(struct azx *chip)
>   to_hda_bus(bus)->bus_probing = 1;
>   hda->probe_continued = 1;
>  
> - /* bind with i915 if needed */
> - if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
> - err = snd_hdac_i915_init(bus, true);
> - if (err < 0) {
> - /* if the controller is bound only with HDMI/DP
> -  * (for HSW and BDW), we need to abort the probe;
> -  * for other chips, still continue probing as other
> -  * codecs can be on the same link.
> -  */
> - if (HDA_CONTROLLER_IN_GPU(pci)) {
> - goto out_free;
> - } else {
> - /* don't bother any longer */
> - chip->driver_caps &= ~AZX_DCAPS_I915_COMPONENT;
> - }
> - }
> -
> - /* HSW/BDW controllers need this power */
> - if (HDA_CONTROLLER_IN_GPU(pci))
> - hda->need_i915_power = true;
> - }
> -
>   /* Request display power well for the HDA controller or codec. For
>* Haswell/Broadwell, both the display HDA controller and codec need
>* this power. For other platforms, like Baytrail/Braswell, only the
> -- 
> 2.40.1

-- 
Ville Syrjälä
Intel

[Intel-gfx] [PATCH v2 3/3] drm/i915: convert vlv_dpio_read()/write() from pipe to phy

2023-11-14 Thread Jani Nikula

vlv_dpio_read() and vlv_dpio_write() really operate on the phy, not
pipe. Passing the pipe instead of the phy as parameter is supposed to be
a convenience, but when the caller has the phy, it becomes an
inconvenience. See e.g. chv_dpio_cmn_power_well_enable() and
assert_chv_phy_powergate().

Figure out the phy in the callers, and pass phy to the dpio functions.

v2: retract one overzealous pipe->phy change (Ville)

Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 .../i915/display/intel_display_power_well.c   |  23 +--
 drivers/gpu/drm/i915/display/intel_dpio_phy.c | 157 +-
 drivers/gpu/drm/i915/display/intel_dpll.c | 106 ++--
 drivers/gpu/drm/i915/vlv_sideband.c   |  10 +-
 drivers/gpu/drm/i915/vlv_sideband.h   |   6 +-
 5 files changed, 151 insertions(+), 151 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c 
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 07d650050099..47cd6bb04366 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -1400,20 +1400,16 @@ static void chv_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
 {
enum i915_power_well_id id = i915_power_well_instance(power_well)->id;
enum dpio_phy phy;
-   enum pipe pipe;
u32 tmp;
 
drm_WARN_ON_ONCE(_priv->drm,
 id != VLV_DISP_PW_DPIO_CMN_BC &&
 id != CHV_DISP_PW_DPIO_CMN_D);
 
-   if (id == VLV_DISP_PW_DPIO_CMN_BC) {
-   pipe = PIPE_A;
+   if (id == VLV_DISP_PW_DPIO_CMN_BC)
phy = DPIO_PHY0;
-   } else {
-   pipe = PIPE_C;
+   else
phy = DPIO_PHY1;
-   }
 
/* since ref/cri clock was enabled */
udelay(1); /* >10ns for cmnreset, >0ns for sidereset */
@@ -1428,24 +1424,24 @@ static void chv_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
vlv_dpio_get(dev_priv);
 
/* Enable dynamic power down */
-   tmp = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW28);
+   tmp = vlv_dpio_read(dev_priv, phy, CHV_CMN_DW28);
tmp |= DPIO_DYNPWRDOWNEN_CH0 | DPIO_CL1POWERDOWNEN |
DPIO_SUS_CLK_CONFIG_GATE_CLKREQ;
-   vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW28, tmp);
+   vlv_dpio_write(dev_priv, phy, CHV_CMN_DW28, tmp);
 
if (id == VLV_DISP_PW_DPIO_CMN_BC) {
-   tmp = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW6_CH1);
+   tmp = vlv_dpio_read(dev_priv, phy, _CHV_CMN_DW6_CH1);
tmp |= DPIO_DYNPWRDOWNEN_CH1;
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW6_CH1, tmp);
+   vlv_dpio_write(dev_priv, phy, _CHV_CMN_DW6_CH1, tmp);
} else {
/*
 * Force the non-existing CL2 off. BXT does this
 * too, so maybe it saves some power even though
 * CL2 doesn't exist?
 */
-   tmp = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW30);
+   tmp = vlv_dpio_read(dev_priv, phy, CHV_CMN_DW30);
tmp |= DPIO_CL2_LDOFUSE_PWRENB;
-   vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW30, tmp);
+   vlv_dpio_write(dev_priv, phy, CHV_CMN_DW30, tmp);
}
 
vlv_dpio_put(dev_priv);
@@ -1499,7 +1495,6 @@ static void chv_dpio_cmn_power_well_disable(struct 
drm_i915_private *dev_priv,
 static void assert_chv_phy_powergate(struct drm_i915_private *dev_priv, enum 
dpio_phy phy,
 enum dpio_channel ch, bool override, 
unsigned int mask)
 {
-   enum pipe pipe = phy == DPIO_PHY0 ? PIPE_A : PIPE_C;
u32 reg, val, expected, actual;
 
/*
@@ -1518,7 +1513,7 @@ static void assert_chv_phy_powergate(struct 
drm_i915_private *dev_priv, enum dpi
reg = _CHV_CMN_DW6_CH1;
 
vlv_dpio_get(dev_priv);
-   val = vlv_dpio_read(dev_priv, pipe, reg);
+   val = vlv_dpio_read(dev_priv, phy, reg);
vlv_dpio_put(dev_priv);
 
/*
diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
index d6af46e33424..4ca910874a4f 100644
--- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
@@ -703,50 +703,50 @@ void chv_set_phy_signal_level(struct intel_encoder 
*encoder,
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
enum dpio_channel ch = vlv_dig_port_to_channel(dig_port);
-   enum pipe pipe = crtc->pipe;
+   enum dpio_phy phy = vlv_pipe_to_phy(crtc->pipe);
u32 val;
int i;
 
vlv_dpio_get(dev_priv);
 
/* Clear calc init */
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
+   val = vlv_dpio_read(dev_priv, phy, VLV_PCS01_DW10(ch));
val &=

[Intel-gfx] [PATCH v2 1/3] drm/i915: move *_crtc_clock_get() to intel_dpll.c

2023-11-14 Thread Jani Nikula

Considering what the functions do, intel_dpll.c is a more suitable
location, and lets us make some functions static while at it.

This also means intel_display.c no longer does any DPIO access.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 171 -
 drivers/gpu/drm/i915/display/intel_display.h  |   2 -
 drivers/gpu/drm/i915/display/intel_dpll.c | 175 +-
 drivers/gpu/drm/i915/display/intel_dpll.h |   9 +-
 .../gpu/drm/i915/display/intel_pch_display.c  |   1 +
 5 files changed, 181 insertions(+), 177 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 125903007a29..959db3f61e84 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -73,7 +73,6 @@
 #include "intel_dp.h"
 #include "intel_dp_link_training.h"
 #include "intel_dp_mst.h"
-#include "intel_dpio_phy.h"
 #include "intel_dpll.h"
 #include "intel_dpll_mgr.h"
 #include "intel_dpt.h"
@@ -2859,67 +2858,6 @@ static void i9xx_get_pfit_config(struct intel_crtc_state 
*crtc_state)
intel_de_read(dev_priv, PFIT_PGM_RATIOS);
 }
 
-static void vlv_crtc_clock_get(struct intel_crtc *crtc,
-  struct intel_crtc_state *pipe_config)
-{
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   enum pipe pipe = crtc->pipe;
-   struct dpll clock;
-   u32 mdiv;
-   int refclk = 10;
-
-   /* In case of DSI, DPLL will not be used */
-   if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
-   return;
-
-   vlv_dpio_get(dev_priv);
-   mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
-   vlv_dpio_put(dev_priv);
-
-   clock.m1 = (mdiv >> DPIO_M1DIV_SHIFT) & 7;
-   clock.m2 = mdiv & DPIO_M2DIV_MASK;
-   clock.n = (mdiv >> DPIO_N_SHIFT) & 0xf;
-   clock.p1 = (mdiv >> DPIO_P1_SHIFT) & 7;
-   clock.p2 = (mdiv >> DPIO_P2_SHIFT) & 0x1f;
-
-   pipe_config->port_clock = vlv_calc_dpll_params(refclk, );
-}
-
-static void chv_crtc_clock_get(struct intel_crtc *crtc,
-  struct intel_crtc_state *pipe_config)
-{
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   enum pipe pipe = crtc->pipe;
-   enum dpio_channel port = vlv_pipe_to_channel(pipe);
-   struct dpll clock;
-   u32 cmn_dw13, pll_dw0, pll_dw1, pll_dw2, pll_dw3;
-   int refclk = 10;
-
-   /* In case of DSI, DPLL will not be used */
-   if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
-   return;
-
-   vlv_dpio_get(dev_priv);
-   cmn_dw13 = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW13(port));
-   pll_dw0 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW0(port));
-   pll_dw1 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW1(port));
-   pll_dw2 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW2(port));
-   pll_dw3 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW3(port));
-   vlv_dpio_put(dev_priv);
-
-   clock.m1 = (pll_dw1 & 0x7) == DPIO_CHV_M1_DIV_BY_2 ? 2 : 0;
-   clock.m2 = (pll_dw0 & 0xff) << 22;
-   if (pll_dw3 & DPIO_CHV_FRAC_DIV_EN)
-   clock.m2 |= pll_dw2 & 0x3f;
-   clock.n = (pll_dw1 >> DPIO_CHV_N_DIV_SHIFT) & 0xf;
-   clock.p1 = (cmn_dw13 >> DPIO_CHV_P1_DIV_SHIFT) & 0x7;
-   clock.p2 = (cmn_dw13 >> DPIO_CHV_P2_DIV_SHIFT) & 0x1f;
-
-   pipe_config->port_clock = chv_calc_dpll_params(refclk, );
-}
-
 static enum intel_output_format
 bdw_get_pipe_misc_output_format(struct intel_crtc *crtc)
 {
@@ -3840,115 +3778,6 @@ bool intel_crtc_get_pipe_config(struct intel_crtc_state 
*crtc_state)
return true;
 }
 
-static int i9xx_pll_refclk(struct drm_device *dev,
-  const struct intel_crtc_state *pipe_config)
-{
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   u32 dpll = pipe_config->dpll_hw_state.dpll;
-
-   if ((dpll & PLL_REF_INPUT_MASK) == PLLB_REF_INPUT_SPREADSPECTRUMIN)
-   return dev_priv->display.vbt.lvds_ssc_freq;
-   else if (HAS_PCH_SPLIT(dev_priv))
-   return 12;
-   else if (DISPLAY_VER(dev_priv) != 2)
-   return 96000;
-   else
-   return 48000;
-}
-
-/* Returns the clock of the currently programmed mode of the given pipe. */
-void i9xx_crtc_clock_get(struct intel_crtc *crtc,
-struct intel_crtc_state *pipe_config)
-{
-   struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   u32 dpll = pipe_config->dpll_hw_state.dpll;
-   u32 fp;
-   struct dpll clock;
-   int port_clock;
-   int refclk = i9xx_pll_refclk(dev, pipe_config);
-
-   if ((dpll & DISPLAY_RATE_SELECT_FPA1) == 0)
-   fp =

[Intel-gfx] [PATCH v2 2/3] drm/i915: add vlv_pipe_to_phy() helper to replace DPIO_PHY()

2023-11-14 Thread Jani Nikula

Add a helper with better typing and handing for bogus input, and better
in line with vlv_dig_port_to_channel(), vlv_dig_port_to_phy(), and
vlv_pipe_to_channel().

Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dpio_phy.c | 14 ++
 drivers/gpu/drm/i915/display/intel_dpio_phy.h |  5 +
 drivers/gpu/drm/i915/display/intel_pps.c  |  2 +-
 drivers/gpu/drm/i915/i915_reg.h   |  2 --
 drivers/gpu/drm/i915/vlv_sideband.c   |  6 --
 5 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
index 62b93d097e44..d6af46e33424 100644
--- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
@@ -666,6 +666,20 @@ enum dpio_phy vlv_dig_port_to_phy(struct 
intel_digital_port *dig_port)
}
 }
 
+enum dpio_phy vlv_pipe_to_phy(enum pipe pipe)
+{
+   switch (pipe) {
+   default:
+   MISSING_CASE(pipe);
+   fallthrough;
+   case PIPE_A:
+   case PIPE_B:
+   return DPIO_PHY0;
+   case PIPE_C:
+   return DPIO_PHY1;
+   }
+}
+
 enum dpio_channel vlv_pipe_to_channel(enum pipe pipe)
 {
switch (pipe) {
diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.h 
b/drivers/gpu/drm/i915/display/intel_dpio_phy.h
index 4d43dbbdf81c..9adc4e8c1738 100644
--- a/drivers/gpu/drm/i915/display/intel_dpio_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.h
@@ -44,6 +44,7 @@ u8 bxt_ddi_phy_get_lane_lat_optim_mask(struct intel_encoder 
*encoder);
 
 enum dpio_channel vlv_dig_port_to_channel(struct intel_digital_port *dig_port);
 enum dpio_phy vlv_dig_port_to_phy(struct intel_digital_port *dig_port);
+enum dpio_phy vlv_pipe_to_phy(enum pipe pipe);
 enum dpio_channel vlv_pipe_to_channel(enum pipe pipe);
 
 void chv_set_phy_signal_level(struct intel_encoder *encoder,
@@ -116,6 +117,10 @@ static inline enum dpio_phy vlv_dig_port_to_phy(struct 
intel_digital_port *dig_p
 {
return DPIO_PHY0;
 }
+static inline enum dpio_phy vlv_pipe_to_phy(enum pipe pipe)
+{
+   return DPIO_PHY0;
+}
 static inline enum dpio_channel vlv_pipe_to_channel(enum pipe pipe)
 {
return DPIO_CH0;
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
b/drivers/gpu/drm/i915/display/intel_pps.c
index 73f0f1714b37..a8fa3a20990e 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -90,7 +90,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
enum pipe pipe = intel_dp->pps.pps_pipe;
bool pll_enabled, release_cl_override = false;
-   enum dpio_phy phy = DPIO_PHY(pipe);
+   enum dpio_phy phy = vlv_pipe_to_phy(pipe);
enum dpio_channel ch = vlv_pipe_to_channel(pipe);
u32 DP;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 135e8d8dbdf0..27dc903f0553 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -195,8 +195,6 @@
 #define  DPIO_SFR_BYPASS   (1 << 1)
 #define  DPIO_CMNRST   (1 << 0)
 
-#define DPIO_PHY(pipe) ((pipe) >> 1)
-
 /*
  * Per pipe/PLL DPIO regs
  */
diff --git a/drivers/gpu/drm/i915/vlv_sideband.c 
b/drivers/gpu/drm/i915/vlv_sideband.c
index b98dec3ad817..f7df55217845 100644
--- a/drivers/gpu/drm/i915/vlv_sideband.c
+++ b/drivers/gpu/drm/i915/vlv_sideband.c
@@ -229,7 +229,8 @@ static u32 vlv_dpio_phy_iosf_port(struct drm_i915_private 
*i915, enum dpio_phy p
 
 u32 vlv_dpio_read(struct drm_i915_private *i915, enum pipe pipe, int reg)
 {
-   u32 port = vlv_dpio_phy_iosf_port(i915, DPIO_PHY(pipe));
+   enum dpio_phy phy = vlv_pipe_to_phy(pipe);
+   u32 port = vlv_dpio_phy_iosf_port(i915, phy);
u32 val = 0;
 
vlv_sideband_rw(i915, DPIO_DEVFN, port, SB_MRD_NP, reg, );
@@ -248,7 +249,8 @@ u32 vlv_dpio_read(struct drm_i915_private *i915, enum pipe 
pipe, int reg)
 void vlv_dpio_write(struct drm_i915_private *i915,
enum pipe pipe, int reg, u32 val)
 {
-   u32 port = vlv_dpio_phy_iosf_port(i915, DPIO_PHY(pipe));
+   enum dpio_phy phy = vlv_pipe_to_phy(pipe);
+   u32 port = vlv_dpio_phy_iosf_port(i915, phy);
 
vlv_sideband_rw(i915, DPIO_DEVFN, port, SB_MWR_NP, reg, );
 }
-- 
2.39.2

Re: [Intel-gfx] [PATCH 4/4] drm/i915: move sideband regs to vlv_sideband_reg.h

2023-11-14 Thread Jani Nikula

On Tue, 14 Nov 2023, Ville Syrjälä  wrote:
> On Mon, Nov 13, 2023 at 06:47:11PM +0200, Jani Nikula wrote:
>> Move the VLV/CHV sideband doorbell and data/addr MMIO registers as well
>> as the DPIO register definitions to vlv_sideband_reg.h.
>
> I have patches sitting in a branch to extract {vlv,bxt}_dpio_phy_regs.h
> instead. I think that split makes more sense in terms of how the
> hardware is structured.

I don't disagree. I'll drop this patch, please rebase yours once 1-3
have been merged. I'll send v2 of them shortly.

BR,
Jani.


>
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h | 374 ---
>>  drivers/gpu/drm/i915/vlv_sideband_reg.h | 377 
>>  2 files changed, 377 insertions(+), 374 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 27dc903f0553..cd3974127b66 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -158,386 +158,12 @@
>>  #define  DEBUG_RESET_RENDER (1 << 8)
>>  #define  DEBUG_RESET_DISPLAY(1 << 9)
>>  
>> -/*
>> - * IOSF sideband
>> - */
>> -#define VLV_IOSF_DOORBELL_REQ   _MMIO(VLV_DISPLAY_BASE 
>> + 0x2100)
>> -#define   IOSF_DEVFN_SHIFT  24
>> -#define   IOSF_OPCODE_SHIFT 16
>> -#define   IOSF_PORT_SHIFT   8
>> -#define   IOSF_BYTE_ENABLES_SHIFT   4
>> -#define   IOSF_BAR_SHIFT1
>> -#define   IOSF_SB_BUSY  (1 << 0)
>> -#define   IOSF_PORT_BUNIT   0x03
>> -#define   IOSF_PORT_PUNIT   0x04
>> -#define   IOSF_PORT_NC  0x11
>> -#define   IOSF_PORT_DPIO0x12
>> -#define   IOSF_PORT_GPIO_NC 0x13
>> -#define   IOSF_PORT_CCK 0x14
>> -#define   IOSF_PORT_DPIO_2  0x1a
>> -#define   IOSF_PORT_FLISDSI 0x1b
>> -#define   IOSF_PORT_GPIO_SC 0x48
>> -#define   IOSF_PORT_GPIO_SUS0xa8
>> -#define   IOSF_PORT_CCU 0xa9
>> -#define   CHV_IOSF_PORT_GPIO_N  0x13
>> -#define   CHV_IOSF_PORT_GPIO_SE 0x48
>> -#define   CHV_IOSF_PORT_GPIO_E  0xa8
>> -#define   CHV_IOSF_PORT_GPIO_SW 0xb2
>> -#define VLV_IOSF_DATA   _MMIO(VLV_DISPLAY_BASE 
>> + 0x2104)
>> -#define VLV_IOSF_ADDR   _MMIO(VLV_DISPLAY_BASE 
>> + 0x2108)
>> -
>> -/* DPIO registers */
>> -#define DPIO_DEVFN  0
>> -
>>  #define DPIO_CTL_MMIO(VLV_DISPLAY_BASE + 0x2110)
>>  #define  DPIO_MODSEL1   (1 << 3) /* if ref clk b == 27 
>> */
>>  #define  DPIO_MODSEL0   (1 << 2) /* if ref clk a == 27 
>> */
>>  #define  DPIO_SFR_BYPASS(1 << 1)
>>  #define  DPIO_CMNRST(1 << 0)
>>  
>> -/*
>> - * Per pipe/PLL DPIO regs
>> - */
>> -#define _VLV_PLL_DW3_CH00x800c
>> -#define   DPIO_POST_DIV_SHIFT   (28) /* 3 bits */
>> -#define   DPIO_POST_DIV_DAC 0
>> -#define   DPIO_POST_DIV_HDMIDP  1 /* DAC 225-400M rate */
>> -#define   DPIO_POST_DIV_LVDS1   2
>> -#define   DPIO_POST_DIV_LVDS2   3
>> -#define   DPIO_K_SHIFT  (24) /* 4 bits */
>> -#define   DPIO_P1_SHIFT (21) /* 3 bits */
>> -#define   DPIO_P2_SHIFT (16) /* 5 bits */
>> -#define   DPIO_N_SHIFT  (12) /* 4 bits */
>> -#define   DPIO_ENABLE_CALIBRATION   (1 << 11)
>> -#define   DPIO_M1DIV_SHIFT  (8) /* 3 bits */
>> -#define   DPIO_M2DIV_MASK   0xff
>> -#define _VLV_PLL_DW3_CH10x802c
>> -#define VLV_PLL_DW3(ch) _PIPE(ch, _VLV_PLL_DW3_CH0, _VLV_PLL_DW3_CH1)
>> -
>> -#define _VLV_PLL_DW5_CH00x8014
>> -#define   DPIO_REFSEL_OVERRIDE  27
>> -#define   DPIO_PLL_MODESEL_SHIFT24 /* 3 bits */
>> -#define   DPIO_BIAS_CURRENT_CTL_SHIFT   21 /* 3 bits, always 0x7 */
>> -#define   DPIO_PLL_REFCLK_SEL_SHIFT 16 /* 2 bits */
>> -#define   DPIO_PLL_REFCLK_SEL_MASK  3
>> -#define   DPIO_DRIVER_CTL_SHIFT 12 /* always set to 0x8 */
>> -#define   DPIO_CLK_BIAS_CTL_SHIFT   8 /* always set to 0x5 */
>> -#define _VLV_PLL_DW5_CH10x8034
>> -#define VLV_PLL_DW5(ch) _PIPE(ch, _VLV_PLL_DW5_CH0, _VLV_PLL_DW5_CH1)
>> -
>> -#define _VLV_PLL_DW7_CH00x801c
>> -#define _VLV_PLL_DW7_CH10x803c
>> -#define VLV_PLL_DW7(ch) _PIPE(ch, _VLV_PLL_DW7_CH0, _VLV_PLL_DW7_CH1)
>> -
>> -#define _VLV_PLL_DW8_CH00x8040
>> -#define _VLV_PLL_DW8_CH10x8060
>> -#define VLV_PLL_DW8(ch) _PIPE(ch, _VLV_PLL_DW8_CH0, _VLV_PLL_DW8_CH1)
>> -
>> -#define VLV_PLL_DW9_BCAST   0xc044
>> -#define _VLV_PLL_DW9_CH0

Re: [Intel-gfx] [PATCH 3/4] drm/i915: convert vlv_dpio_read()/write() from pipe to phy

2023-11-14 Thread Jani Nikula

On Tue, 14 Nov 2023, Ville Syrjälä  wrote:
> On Mon, Nov 13, 2023 at 06:47:10PM +0200, Jani Nikula wrote:
>> vlv_dpio_read() and vlv_dpio_write() really operate on the phy, not
>> pipe. Passing the pipe instead of the phy as parameter is supposed to be
>> a convenience, but when the caller has the phy, it becomes an
>> inconvenience. See e.g. chv_dpio_cmn_power_well_enable() and
>> assert_chv_phy_powergate().
>> 
>> Figure out the phy in the callers, and pass phy to the dpio functions.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  .../i915/display/intel_display_power_well.c   |  23 +--
>>  drivers/gpu/drm/i915/display/intel_dpio_phy.c | 160 +-
>>  drivers/gpu/drm/i915/display/intel_dpll.c | 106 ++--
>>  drivers/gpu/drm/i915/vlv_sideband.c   |  10 +-
>>  drivers/gpu/drm/i915/vlv_sideband.h   |   6 +-
>>  5 files changed, 152 insertions(+), 153 deletions(-)
> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
>> b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
>> index d6af46e33424..32886c0ec2cc 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
>> @@ -1107,24 +1109,24 @@ void vlv_phy_pre_encoder_enable(struct intel_encoder 
>> *encoder,
>>  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>>  struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>>  enum dpio_channel port = vlv_dig_port_to_channel(dig_port);
>> -enum pipe pipe = crtc->pipe;
>> +enum dpio_phy phy = vlv_pipe_to_phy(crtc->pipe);
>>  u32 val;
>>  
>>  vlv_dpio_get(dev_priv);
>>  
>>  /* Enable clock channels for this port */
>> -val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(port));
>> +val = vlv_dpio_read(dev_priv, phy, VLV_PCS01_DW8(port));
>>  val = 0;
>> -if (pipe)
>> +if (phy)
>
> That is wrong. Apart from that looks identical to what I have in
> one of my branches :)

Whoops, over eager replace. Good catch!

>
> With that bogus change dropped:
> Reviewed-by: Ville Syrjälä 

Thanks!

-- 
Jani Nikula, Intel

Re: [Intel-gfx] [PATCH 00/11] Add DSC fractional bpp support

2023-11-14 Thread Nautiyal, Ankit K




On 11/10/2023 3:40 PM, Ankit Nautiyal wrote:

This patch series adds support for DSC fractional compressed bpp
for MTL+. The series starts with some fixes, followed by patches that
lay groundwork to iterate over valid compressed bpps to select the
'best' compressed bpp with optimal link configuration (taken from
upstream series: https://patchwork.freedesktop.org/series/105200/).

The later patches, add changes to accommodate compressed bpp with
fractional part, including changes to QP calculations.
To get the 'best' compressed bpp, we iterate over the valid compressed
bpp values, but with fractional step size 1/16, 1/8, 1/4 or 1/2 as per
sink support.

The last 2 patches add support to depict DSC sink's fractional support,
and debugfs to enforce use of fractional bpp, while choosing an
appropriate compressed bpp.

Rev10: Rebased and added DSC Fractional support for DP MST.


Pushed patches 1-8 to drm-intel-next, thanks for the reviews, acks.

Regards,

Ankit




Ankit Nautiyal (8):
   drm/display/dp: Add helper function to get DSC bpp precision
   drm/i915/display: Store compressed bpp in U6.4 format
   drm/i915/display: Consider fractional vdsc bpp while computing m_n
 values
   drm/i915/audio: Consider fractional vdsc bpp while computing tu_data
   drm/i915/dp: Iterate over output bpp with fractional step size
   drm/i915/dp_mst: Use precision of 1/16 for computing bpp
   drm/i916/dp_mst: Iterate over the DSC bpps as per DSC precision
 support
   drm/i915/dp_mst: Add support for forcing dsc fractional bpp via
 debugfs

Swati Sharma (2):
   drm/i915/dsc: Add debugfs entry to validate DSC fractional bpp
   drm/i915/dsc: Allow DSC only with fractional bpp when forced from
 debugfs

Vandita Kulkarni (1):
   drm/i915/dsc/mtl: Add support for fractional bpp

  drivers/gpu/drm/display/drm_dp_helper.c   | 27 ++
  drivers/gpu/drm/i915/display/icl_dsi.c| 10 +--
  drivers/gpu/drm/i915/display/intel_audio.c| 16 ++--
  drivers/gpu/drm/i915/display/intel_bios.c |  4 +-
  drivers/gpu/drm/i915/display/intel_cdclk.c|  5 +-
  drivers/gpu/drm/i915/display/intel_display.c  |  6 +-
  .../drm/i915/display/intel_display_debugfs.c  | 84 ++
  .../drm/i915/display/intel_display_types.h|  4 +-
  drivers/gpu/drm/i915/display/intel_dp.c   | 87 +++
  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 85 +++---
  drivers/gpu/drm/i915/display/intel_fdi.c  |  3 +-
  drivers/gpu/drm/i915/display/intel_link_bw.c  |  2 +-
  .../gpu/drm/i915/display/intel_qp_tables.c|  3 -
  drivers/gpu/drm/i915/display/intel_vdsc.c | 29 +--
  include/drm/display/drm_dp_helper.h   |  1 +
  15 files changed, 266 insertions(+), 100 deletions(-)

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Use int for entry setup frames

2023-11-14 Thread Kahola, Mika

> -Original Message-
> From: Hajda, Andrzej 
> Sent: Tuesday, November 14, 2023 12:22 PM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Use int for entry setup frames
> 
> On 13.11.2023 10:37, Mika Kahola wrote:
> > At least one TGL had regression when using u8 types for entry setup
> > frames calculation. So, let's switch to use ints instead.
> 
> This explanation is missing the most important part - why int?
> 
> I guess it is because intel_psr_entry_setup_frames can return -ETIME, which 
> converted to u8 and then int becomes not what we
> would expect.
> And fixes tag is missing.

I will add the fixes and improve the explanation.

Thanks for the comments and reviews.

-Mika-
> 
> Regards
> Andrzej
> 
> >
> > Signed-off-by: Mika Kahola 
> > ---
> >   drivers/gpu/drm/i915/display/intel_psr.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 3691f882e1c0..a4417e85f92a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1093,12 +1093,12 @@ static bool _compute_psr2_wake_times(struct 
> > intel_dp *intel_dp,
> > return true;
> >   }
> >
> > -static u8 intel_psr_entry_setup_frames(struct intel_dp *intel_dp,
> > -  const struct drm_display_mode 
> > *adjusted_mode)
> > +static int intel_psr_entry_setup_frames(struct intel_dp *intel_dp,
> > +   const struct drm_display_mode 
> > *adjusted_mode)
> >   {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > int psr_setup_time = drm_dp_psr_setup_time(intel_dp->psr_dpcd);
> > -   u8 entry_setup_frames = 0;
> > +   int entry_setup_frames = 0;
> >
> > if (psr_setup_time < 0) {
> > drm_dbg_kms(>drm,

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Use int for entry setup frames

2023-11-14 Thread Andrzej Hajda


On 13.11.2023 10:37, Mika Kahola wrote:

At least one TGL had regression when using u8 types
for entry setup frames calculation. So, let's switch
to use ints instead.


This explanation is missing the most important part - why int?

I guess it is because intel_psr_entry_setup_frames can return -ETIME, 
which converted to u8 and then int becomes not what we would expect.

And fixes tag is missing.

Regards
Andrzej



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

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 3691f882e1c0..a4417e85f92a 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1093,12 +1093,12 @@ static bool _compute_psr2_wake_times(struct intel_dp 
*intel_dp,
return true;
  }
  
-static u8 intel_psr_entry_setup_frames(struct intel_dp *intel_dp,

-  const struct drm_display_mode 
*adjusted_mode)
+static int intel_psr_entry_setup_frames(struct intel_dp *intel_dp,
+   const struct drm_display_mode 
*adjusted_mode)
  {
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int psr_setup_time = drm_dp_psr_setup_time(intel_dp->psr_dpcd);
-   u8 entry_setup_frames = 0;
+   int entry_setup_frames = 0;
  
  	if (psr_setup_time < 0) {

drm_dbg_kms(>drm,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/xe2lpd: WA for underruns during FBC enable (rev3)

2023-11-14 Thread Patchwork

== Series Details ==

Series: drm/i915/xe2lpd: WA for underruns during FBC enable (rev3)
URL   : https://patchwork.freedesktop.org/series/126143/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13865 -> Patchwork_126143v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (33 -> 33)
--

  Additional (1): fi-hsw-4770 
  Missing(1): bat-rpls-1 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][1] -> [ABORT][2] ([i915#9662])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13865/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * 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_13865/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
- fi-apl-guc: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13865/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@gt_pm:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][7] ([i915#9642])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/fi-hsw-4770/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@slpc:
- fi-kbl-soraka:  NOTRUN -> [ABORT][8] ([i915#9663])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/fi-kbl-soraka/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-jsl-3:  [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13865/bat-jsl-3/igt@i915_susp...@basic-s2idle-without-i915.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/bat-jsl-3/igt@i915_susp...@basic-s2idle-without-i915.html

  * igt@i915_suspend@basic-s3-without-i915:
- bat-jsl-3:  [PASS][11] -> [INCOMPLETE][12] ([i915#9664])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13865/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html

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

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1:
- fi-hsw-4770:NOTRUN -> [SKIP][14] ([fdo#109271]) +12 other tests 
skip
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html

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

  
 Possible fixes 

  * igt@kms_psr@sprite_plane_onoff:
- bat-jsl-3:  [SKIP][16] ([i915#9648]) -> [PASS][17] +3 other tests 
pass
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13865/bat-jsl-3/igt@kms_psr@sprite_plane_onoff.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126143v3/bat-jsl-3/igt@kms_psr@sprite_plane_onoff.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#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
  [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
  [i915#8981]: https://gitlab.freedesktop.org/drm/intel/issues/8981
  [i915#9642]: https://gitlab.freedesktop.org/drm/intel/issues/9642
  [i915#9648]: https://gitlab.freedesktop.org/drm/intel/issues/9648
  [i915#9662]: https://gitlab.freedesktop.org/drm/intel/issues/9662
  [i915#9663]:

Re: [Intel-gfx] [1/3] drm/i915/display: Separate xe and i915 common dpt code into own file

2023-11-14 Thread Hogander, Jouni

On Mon, 2023-11-13 at 22:32 +0200, Juha-Pekka Heikkila wrote:
> Here created intel_dpt_common.c to hold intel_dpt_configure which is
> needed for both xe and i915.

For the whole series:

Reviewed-by: Jouni Högander 

BR,

Jouni Högander


> Signed-off-by: Juha-Pekka Heikkila 
> ---
>  drivers/gpu/drm/i915/Makefile |  1 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>  drivers/gpu/drm/i915/display/intel_dpt.c  | 26 --
>  drivers/gpu/drm/i915/display/intel_dpt.h  |  2 --
>  .../gpu/drm/i915/display/intel_dpt_common.c   | 34
> +++
>  .../gpu/drm/i915/display/intel_dpt_common.h   | 13 +++
>  6 files changed, 49 insertions(+), 28 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dpt_common.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dpt_common.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 239da40a401f..c18a20c47265 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -275,6 +275,7 @@ i915-y += \
> display/intel_dpll.o \
> display/intel_dpll_mgr.o \
> display/intel_dpt.o \
> +   display/intel_dpt_common.o \
> display/intel_drrs.o \
> display/intel_dsb.o \
> display/intel_fb.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3effafcbb411..12c163203658 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -77,6 +77,7 @@
>  #include "intel_dpll.h"
>  #include "intel_dpll_mgr.h"
>  #include "intel_dpt.h"
> +#include "intel_dpt_common.h"
>  #include "intel_drrs.h"
>  #include "intel_dsb.h"
>  #include "intel_dsi.h"
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> b/drivers/gpu/drm/i915/display/intel_dpt.c
> index 2b067cb952f0..b29bceff73f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -9,8 +9,6 @@
>  #include "gt/gen8_ppgtt.h"
>  
>  #include "i915_drv.h"
> -#include "i915_reg.h"
> -#include "intel_de.h"
>  #include "intel_display_types.h"
>  #include "intel_dpt.h"
>  #include "intel_fb.h"
> @@ -318,27 +316,3 @@ void intel_dpt_destroy(struct i915_address_space
> *vm)
> i915_vm_put(>vm);
>  }
>  
> -void intel_dpt_configure(struct intel_crtc *crtc)
> -{
> -   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> -
> -   if (DISPLAY_VER(i915) == 14) {
> -   enum pipe pipe = crtc->pipe;
> -   enum plane_id plane_id;
> -
> -   for_each_plane_id_on_crtc(crtc, plane_id) {
> -   if (plane_id == PLANE_CURSOR)
> -   continue;
> -
> -   intel_de_rmw(i915, PLANE_CHICKEN(pipe,
> plane_id),
> -    PLANE_CHICKEN_DISABLE_DPT,
> -    i915->display.params.enable_dpt
> ? 0 :
> -    PLANE_CHICKEN_DISABLE_DPT);
> -   }
> -   } else if (DISPLAY_VER(i915) == 13) {
> -   intel_de_rmw(i915, CHICKEN_MISC_2,
> -    CHICKEN_MISC_DISABLE_DPT,
> -    i915->display.params.enable_dpt ? 0 :
> -    CHICKEN_MISC_DISABLE_DPT);
> -   }
> -}
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.h
> b/drivers/gpu/drm/i915/display/intel_dpt.h
> index d9a166550185..e18a9f767b11 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.h
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.h
> @@ -10,7 +10,6 @@ struct drm_i915_private;
>  
>  struct i915_address_space;
>  struct i915_vma;
> -struct intel_crtc;
>  struct intel_framebuffer;
>  
>  void intel_dpt_destroy(struct i915_address_space *vm);
> @@ -20,6 +19,5 @@ void intel_dpt_suspend(struct drm_i915_private
> *i915);
>  void intel_dpt_resume(struct drm_i915_private *i915);
>  struct i915_address_space *
>  intel_dpt_create(struct intel_framebuffer *fb);
> -void intel_dpt_configure(struct intel_crtc *crtc);
>  
>  #endif /* __INTEL_DPT_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt_common.c
> b/drivers/gpu/drm/i915/display/intel_dpt_common.c
> new file mode 100644
> index ..cdba47165c04
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_dpt_common.c
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2023 Intel Corporation
> + */
> +
> +#include "i915_reg.h"
> +#include "intel_de.h"
> +#include "intel_display_types.h"
> +#include "intel_dpt_common.h"
> +
> +void intel_dpt_configure(struct intel_crtc *crtc)
> +{
> +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> +
> +   if (DISPLAY_VER(i915) == 14) {
> +   enum pipe pipe = crtc->pipe;
> +   enum plane_id plane_id;
> +
> +   for_each_plane_id_on_crtc(crtc, plane_id) {
> +

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Use int for entry setup frames

2023-11-14 Thread Hogander, Jouni

On Mon, 2023-11-13 at 11:37 +0200, Mika Kahola wrote:
> At least one TGL had regression when using u8 types
> for entry setup frames calculation. So, let's switch
> to use ints instead.

I think you need to add Fixes tag here? With this change:

Reviewed-by: Jouni Högander 

> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 3691f882e1c0..a4417e85f92a 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1093,12 +1093,12 @@ static bool _compute_psr2_wake_times(struct
> intel_dp *intel_dp,
> return true;
>  }
>  
> -static u8 intel_psr_entry_setup_frames(struct intel_dp *intel_dp,
> -  const struct drm_display_mode
> *adjusted_mode)
> +static int intel_psr_entry_setup_frames(struct intel_dp *intel_dp,
> +   const struct drm_display_mode
> *adjusted_mode)
>  {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> int psr_setup_time = drm_dp_psr_setup_time(intel_dp-
> >psr_dpcd);
> -   u8 entry_setup_frames = 0;
> +   int entry_setup_frames = 0;
>  
> if (psr_setup_time < 0) {
> drm_dbg_kms(>drm,

[Intel-gfx] [PATCH] drm/i915: do not clean GT table on error path

2023-11-14 Thread Andrzej Hajda

The only task of intel_gt_release_all is to zero gt table. Calling
it on error path prevents intel_gt_driver_late_release_all (called from
i915_driver_late_release) to cleanup GTs, causing leakage.
After i915_driver_late_release GT array is not used anymore so
it does not need cleaning at all.

Sample leak report:

BUG i915_request (...): Objects remaining in i915_request on 
__kmem_cache_shutdown()
...
Object 0x888113420040 @offset=64
Allocated in __i915_request_create+0x75/0x610 [i915] age=18339 cpu=1 pid=1454
 kmem_cache_alloc+0x25b/0x270
 __i915_request_create+0x75/0x610 [i915]
 i915_request_create+0x109/0x290 [i915]
 __engines_record_defaults+0xca/0x440 [i915]
 intel_gt_init+0x275/0x430 [i915]
 i915_gem_init+0x135/0x2c0 [i915]
 i915_driver_probe+0x8d1/0xdc0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8489
Fixes: bec68cc9ea42d8 ("drm/i915: Prepare for multiple GTs")
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/i915_driver.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 80e85cadb9a262..428ace0bebaac9 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -782,7 +782,7 @@ int i915_driver_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
ret = i915_driver_mmio_probe(i915);
if (ret < 0)
-   goto out_tiles_cleanup;
+   goto out_runtime_pm_put;
 
ret = i915_driver_hw_probe(i915);
if (ret < 0)
@@ -842,8 +842,6 @@ int i915_driver_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
i915_ggtt_driver_late_release(i915);
 out_cleanup_mmio:
i915_driver_mmio_release(i915);
-out_tiles_cleanup:
-   intel_gt_release_all(i915);
 out_runtime_pm_put:
enable_rpm_wakeref_asserts(>runtime_pm);
i915_driver_late_release(i915);

---
base-commit: c6f47b4817ee55a02359c3347a298876cfa93b0e
change-id: 20231114-dont_clean_gt_on_error_path-91cd9c3caa0a

Best regards,
-- 
Andrzej Hajda

Re: [Intel-gfx] [PATCH 04/11] drm/i915/audio: Consider fractional vdsc bpp while computing tu_data

2023-11-14 Thread Kandpal, Suraj

> MTL+ supports fractional compressed bits_per_pixel, with precision of
> 1/16. This compressed bpp is stored in U6.4 format.
> Accommodate the precision during calculation of transfer unit data for
> hblank_early calculation.
> 
> v2:
> -Fix tu_data calculation while dealing with U6.4 format. (Stan)
> 
> v3:
> -Use BPP_X16_FMT to print vdsc bpp.
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Signed-off-by: Ankit Nautiyal 
> Reviewed-by: Suraj Kandpal 
> Reviewed-by: Sui Jingfeng 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index aa93ccd6c2aa..8796d90c46a6 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -521,25 +521,25 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   unsigned int link_clks_available, link_clks_required;
>   unsigned int tu_data, tu_line, link_clks_active;
>   unsigned int h_active, h_total, hblank_delta, pixel_clk;
> - unsigned int fec_coeff, cdclk, vdsc_bpp;
> + unsigned int fec_coeff, cdclk, vdsc_bppx16;
>   unsigned int link_clk, lanes;
>   unsigned int hblank_rise;
> 
>   h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
>   pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> - vdsc_bpp = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
> + vdsc_bppx16 = crtc_state->dsc.compressed_bpp_x16;
>   cdclk = i915->display.cdclk.hw.cdclk;
>   /* fec= 0.972261, using rounding multiplier of 100 */
>   fec_coeff = 972261;
>   link_clk = crtc_state->port_clock;
>   lanes = crtc_state->lane_count;
> 
> - drm_dbg_kms(>drm, "h_active = %u link_clk = %u :"
> - "lanes = %u vdsc_bpp = %u cdclk = %u\n",
> - h_active, link_clk, lanes, vdsc_bpp, cdclk);
> + drm_dbg_kms(>drm,
> + "h_active = %u link_clk = %u : lanes = %u vdsc_bpp = "
> BPP_X16_FMT " cdclk = %u\n",
> + h_active, link_clk, lanes, BPP_X16_ARGS(vdsc_bppx16),
> cdclk);
> 
> - if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bpp || !cdclk))
> + if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bppx16 ||
> +!cdclk))
>   return 0;
> 
>   link_clks_available = (h_total - h_active) * link_clk / pixel_clk - 28; 
> @@
> -551,8 +551,8 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   hblank_delta = DIV64_U64_ROUND_UP(mul_u32_u32(5 *
> (link_clk + cdclk), pixel_clk),
> mul_u32_u32(link_clk,
> cdclk));
> 
> - tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bpp * 8,
> 100),
> - mul_u32_u32(link_clk * lanes, fec_coeff));
> + tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bppx16 * 8,
> 100),
> + mul_u32_u32(link_clk * lanes * 16, fec_coeff));
>   tu_line = div64_u64(h_active * mul_u32_u32(link_clk, fec_coeff),
>   mul_u32_u32(64 * pixel_clk, 100));
>   link_clks_active  = (tu_line - 1) * 64 + tu_data;
> --
> 2.40.1

Re: [Intel-gfx] [PATCH 4/4] drm/i915: move sideband regs to vlv_sideband_reg.h

2023-11-14 Thread Ville Syrjälä

On Mon, Nov 13, 2023 at 06:47:11PM +0200, Jani Nikula wrote:
> Move the VLV/CHV sideband doorbell and data/addr MMIO registers as well
> as the DPIO register definitions to vlv_sideband_reg.h.

I have patches sitting in a branch to extract {vlv,bxt}_dpio_phy_regs.h
instead. I think that split makes more sense in terms of how the
hardware is structured.

> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 374 ---
>  drivers/gpu/drm/i915/vlv_sideband_reg.h | 377 
>  2 files changed, 377 insertions(+), 374 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 27dc903f0553..cd3974127b66 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -158,386 +158,12 @@
>  #define  DEBUG_RESET_RENDER  (1 << 8)
>  #define  DEBUG_RESET_DISPLAY (1 << 9)
>  
> -/*
> - * IOSF sideband
> - */
> -#define VLV_IOSF_DOORBELL_REQ_MMIO(VLV_DISPLAY_BASE 
> + 0x2100)
> -#define   IOSF_DEVFN_SHIFT   24
> -#define   IOSF_OPCODE_SHIFT  16
> -#define   IOSF_PORT_SHIFT8
> -#define   IOSF_BYTE_ENABLES_SHIFT4
> -#define   IOSF_BAR_SHIFT 1
> -#define   IOSF_SB_BUSY   (1 << 0)
> -#define   IOSF_PORT_BUNIT0x03
> -#define   IOSF_PORT_PUNIT0x04
> -#define   IOSF_PORT_NC   0x11
> -#define   IOSF_PORT_DPIO 0x12
> -#define   IOSF_PORT_GPIO_NC  0x13
> -#define   IOSF_PORT_CCK  0x14
> -#define   IOSF_PORT_DPIO_2   0x1a
> -#define   IOSF_PORT_FLISDSI  0x1b
> -#define   IOSF_PORT_GPIO_SC  0x48
> -#define   IOSF_PORT_GPIO_SUS 0xa8
> -#define   IOSF_PORT_CCU  0xa9
> -#define   CHV_IOSF_PORT_GPIO_N   0x13
> -#define   CHV_IOSF_PORT_GPIO_SE  0x48
> -#define   CHV_IOSF_PORT_GPIO_E   0xa8
> -#define   CHV_IOSF_PORT_GPIO_SW  0xb2
> -#define VLV_IOSF_DATA_MMIO(VLV_DISPLAY_BASE 
> + 0x2104)
> -#define VLV_IOSF_ADDR_MMIO(VLV_DISPLAY_BASE 
> + 0x2108)
> -
> -/* DPIO registers */
> -#define DPIO_DEVFN   0
> -
>  #define DPIO_CTL _MMIO(VLV_DISPLAY_BASE + 0x2110)
>  #define  DPIO_MODSEL1(1 << 3) /* if ref clk b == 27 
> */
>  #define  DPIO_MODSEL0(1 << 2) /* if ref clk a == 27 
> */
>  #define  DPIO_SFR_BYPASS (1 << 1)
>  #define  DPIO_CMNRST (1 << 0)
>  
> -/*
> - * Per pipe/PLL DPIO regs
> - */
> -#define _VLV_PLL_DW3_CH0 0x800c
> -#define   DPIO_POST_DIV_SHIFT(28) /* 3 bits */
> -#define   DPIO_POST_DIV_DAC  0
> -#define   DPIO_POST_DIV_HDMIDP   1 /* DAC 225-400M rate */
> -#define   DPIO_POST_DIV_LVDS12
> -#define   DPIO_POST_DIV_LVDS23
> -#define   DPIO_K_SHIFT   (24) /* 4 bits */
> -#define   DPIO_P1_SHIFT  (21) /* 3 bits */
> -#define   DPIO_P2_SHIFT  (16) /* 5 bits */
> -#define   DPIO_N_SHIFT   (12) /* 4 bits */
> -#define   DPIO_ENABLE_CALIBRATION(1 << 11)
> -#define   DPIO_M1DIV_SHIFT   (8) /* 3 bits */
> -#define   DPIO_M2DIV_MASK0xff
> -#define _VLV_PLL_DW3_CH1 0x802c
> -#define VLV_PLL_DW3(ch) _PIPE(ch, _VLV_PLL_DW3_CH0, _VLV_PLL_DW3_CH1)
> -
> -#define _VLV_PLL_DW5_CH0 0x8014
> -#define   DPIO_REFSEL_OVERRIDE   27
> -#define   DPIO_PLL_MODESEL_SHIFT 24 /* 3 bits */
> -#define   DPIO_BIAS_CURRENT_CTL_SHIFT21 /* 3 bits, always 0x7 */
> -#define   DPIO_PLL_REFCLK_SEL_SHIFT  16 /* 2 bits */
> -#define   DPIO_PLL_REFCLK_SEL_MASK   3
> -#define   DPIO_DRIVER_CTL_SHIFT  12 /* always set to 0x8 */
> -#define   DPIO_CLK_BIAS_CTL_SHIFT8 /* always set to 0x5 */
> -#define _VLV_PLL_DW5_CH1 0x8034
> -#define VLV_PLL_DW5(ch) _PIPE(ch, _VLV_PLL_DW5_CH0, _VLV_PLL_DW5_CH1)
> -
> -#define _VLV_PLL_DW7_CH0 0x801c
> -#define _VLV_PLL_DW7_CH1 0x803c
> -#define VLV_PLL_DW7(ch) _PIPE(ch, _VLV_PLL_DW7_CH0, _VLV_PLL_DW7_CH1)
> -
> -#define _VLV_PLL_DW8_CH0 0x8040
> -#define _VLV_PLL_DW8_CH1 0x8060
> -#define VLV_PLL_DW8(ch) _PIPE(ch, _VLV_PLL_DW8_CH0, _VLV_PLL_DW8_CH1)
> -
> -#define VLV_PLL_DW9_BCAST0xc044
> -#define _VLV_PLL_DW9_CH0 0x8044
> -#define _VLV_PLL_DW9_CH1 0x8064
> -#define VLV_PLL_DW9(ch) _PIPE(ch, _VLV_PLL_DW9_CH0, _VLV_PLL_DW9_CH1)
> -
> -#define _VLV_PLL_DW10_CH00x8048
> -#define _VLV_PLL_DW10_CH10x8068
> -#define

Re: [Intel-gfx] [PATCH 03/11] drm/i915/display: Consider fractional vdsc bpp while computing m_n values

2023-11-14 Thread Kandpal, Suraj



> MTL+ supports fractional compressed bits_per_pixel, with precision of
> 1/16. This compressed bpp is stored in U6.4 format.
> Accommodate this precision while computing m_n values.
> 
> v1:
> Replace the computation of 'data_clock' with 'data_clock =
> DIV_ROUND_UP(data_clock, 16).' (Sui Jingfeng).
> 
> v2:
> Rebase and pass bits_per_pixel in U6.4 format.
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Signed-off-by: Ankit Nautiyal 
> Signed-off-by: Mitul Golani 
> Reviewed-by: Suraj Kandpal 
> Reviewed-by: Sui Jingfeng 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c |  4 ++--
>  drivers/gpu/drm/i915/display/intel_dp.c  | 16 
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  | 14 +++---
>  drivers/gpu/drm/i915/display/intel_fdi.c |  3 ++-
>  4 files changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b4a8e3087e50..125903007a29 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2415,12 +2415,12 @@ add_bw_alloc_overhead(int link_clock, int
> bw_overhead,  }
> 
>  void
> -intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
> +intel_link_compute_m_n(u16 bits_per_pixel_x16, int nlanes,
>  int pixel_clock, int link_clock,
>  int bw_overhead,
>  struct intel_link_m_n *m_n)
>  {
> - u32 data_clock = bits_per_pixel * pixel_clock;
> + u32 data_clock = DIV_ROUND_UP(bits_per_pixel_x16 * pixel_clock,
> 16);
>   u32 data_m;
>   u32 data_n;
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4ad3718c3c7d..246f50d1f030 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2663,7 +2663,7 @@ static bool can_enable_drrs(struct intel_connector
> *connector,  static void  intel_dp_drrs_compute_config(struct intel_connector
> *connector,
>struct intel_crtc_state *pipe_config,
> -  int link_bpp)
> +  int link_bpp_x16)
>  {
>   struct drm_i915_private *i915 = to_i915(connector->base.dev);
>   const struct drm_display_mode *downclock_mode = @@ -2688,7
> +2688,7 @@ intel_dp_drrs_compute_config(struct intel_connector
> *connector,
>   if (pipe_config->splitter.enable)
>   pixel_clock /= pipe_config->splitter.link_count;
> 
> - intel_link_compute_m_n(link_bpp, pipe_config->lane_count,
> pixel_clock,
> + intel_link_compute_m_n(link_bpp_x16, pipe_config->lane_count,
> +pixel_clock,
>  pipe_config->port_clock,
>  intel_dp_bw_fec_overhead(pipe_config-
> >fec_enable),
>  _config->dp_m2_n2);
> @@ -2792,7 +2792,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>   const struct drm_display_mode *fixed_mode;
>   struct intel_connector *connector = intel_dp->attached_connector;
> - int ret = 0, link_bpp;
> + int ret = 0, link_bpp_x16;
> 
>   if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && encoder-
> >port != PORT_A)
>   pipe_config->has_pch_encoder = true;
> @@ -2841,10 +2841,10 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   drm_dp_enhanced_frame_cap(intel_dp->dpcd);
> 
>   if (pipe_config->dsc.compression_enable)
> - link_bpp = to_bpp_int(pipe_config-
> >dsc.compressed_bpp_x16);
> + link_bpp_x16 = pipe_config->dsc.compressed_bpp_x16;
>   else
> - link_bpp = intel_dp_output_bpp(pipe_config-
> >output_format,
> -pipe_config->pipe_bpp);
> + link_bpp_x16 =
> to_bpp_x16(intel_dp_output_bpp(pipe_config->output_format,
> +   pipe_config-
> >pipe_bpp));
> 
>   if (intel_dp->mso_link_count) {
>   int n = intel_dp->mso_link_count;
> @@ -2868,7 +2868,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
> 
>   intel_dp_audio_compute_config(encoder, pipe_config, conn_state);
> 
> - intel_link_compute_m_n(link_bpp,
> + intel_link_compute_m_n(link_bpp_x16,
>  pipe_config->lane_count,
>  adjusted_mode->crtc_clock,
>  pipe_config->port_clock,
> @@ -2884,7 +2884,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
> 
>   intel_vrr_compute_config(pipe_config, conn_state);
>   intel_psr_compute_config(intel_dp, pipe_config, conn_state);
> - intel_dp_drrs_compute_config(connector, pipe_config, link_bpp);
> + intel_dp_drrs_compute_config(connector, pipe_config,
> link_bpp_x16);
>   intel_dp_compute_vsc_sdp(intel_dp, pipe_config,

Re: [Intel-gfx] [PATCH 3/4] drm/i915: convert vlv_dpio_read()/write() from pipe to phy

2023-11-14 Thread Ville Syrjälä

On Mon, Nov 13, 2023 at 06:47:10PM +0200, Jani Nikula wrote:
> vlv_dpio_read() and vlv_dpio_write() really operate on the phy, not
> pipe. Passing the pipe instead of the phy as parameter is supposed to be
> a convenience, but when the caller has the phy, it becomes an
> inconvenience. See e.g. chv_dpio_cmn_power_well_enable() and
> assert_chv_phy_powergate().
> 
> Figure out the phy in the callers, and pass phy to the dpio functions.
> 
> Signed-off-by: Jani Nikula 
> ---
>  .../i915/display/intel_display_power_well.c   |  23 +--
>  drivers/gpu/drm/i915/display/intel_dpio_phy.c | 160 +-
>  drivers/gpu/drm/i915/display/intel_dpll.c | 106 ++--
>  drivers/gpu/drm/i915/vlv_sideband.c   |  10 +-
>  drivers/gpu/drm/i915/vlv_sideband.h   |   6 +-
>  5 files changed, 152 insertions(+), 153 deletions(-)

> diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> index d6af46e33424..32886c0ec2cc 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> @@ -1107,24 +1109,24 @@ void vlv_phy_pre_encoder_enable(struct intel_encoder 
> *encoder,
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   enum dpio_channel port = vlv_dig_port_to_channel(dig_port);
> - enum pipe pipe = crtc->pipe;
> + enum dpio_phy phy = vlv_pipe_to_phy(crtc->pipe);
>   u32 val;
>  
>   vlv_dpio_get(dev_priv);
>  
>   /* Enable clock channels for this port */
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(port));
> + val = vlv_dpio_read(dev_priv, phy, VLV_PCS01_DW8(port));
>   val = 0;
> - if (pipe)
> + if (phy)

That is wrong. Apart from that looks identical to what I have in
one of my branches :)

With that bogus change dropped:
Reviewed-by: Ville Syrjälä 

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 06/10] drm/i915/spi: spi register with mtd

2023-11-14 Thread Miquel Raynal

Hi Alexander,

+ Michael and Tudor

Folks, any interesting thought about the below discussion?

alexander.usys...@intel.com wrote on Tue, 14 Nov 2023 08:47:34 +:

> >   
> > > > > > > + spi->mtd.writesize = SZ_1; /* 1 byte granularity */  
> > > > > >
> > > > > > You say writesize should be aligned with 4 in your next patch?  
> > > > >
> > > > > We support unaligned write by reading aligned 4bytes,
> > > > > replacing changed bytes there and writing whole 4bytes back.
> > > > > Is there any problem with this approach?  
> > > >
> > > > Is there a reason to do that manually rather than letting the core
> > > > handle the complexity?
> > > >  
> > > I was not aware that core can do this. The core implements above logic
> > > if I put SZ_4 here and caller try to write, say, one byte?
> > > And sync multiple writers?
> > > If so, I can remove manual work, I think, and make the patches smaller.  
> > 
> > I haven't checked in detail but I would expect this yes. Please have a
> > round of tests and if it works, please simplify this part.
> > 
> > Thanks,
> > Miquèl  
> 
> When I put SZ_4 here the "mtd_debug info /dev/mtd0" prints "mtd.writesize = 
> 4",
> but "mtd_debug write /dev/mtd0 128 1 c" passes one byte to
> i915_spi_write (mtd._write callback).
> I suppose that mtd subsystem do not support this.
> Or I did something wrong?
> 


Thanks,
Miquèl

Re: [Intel-gfx] [PATCH 02/11] drm/i915/display: Store compressed bpp in U6.4 format

2023-11-14 Thread Kandpal, Suraj




> -Original Message-
> From: Nautiyal, Ankit K 
> Sent: Friday, November 10, 2023 3:40 PM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Sharma, Swati2 ; Kulkarni, Vandita
> ; Kandpal, Suraj ;
> suijingf...@loongson.cn
> Subject: [PATCH 02/11] drm/i915/display: Store compressed bpp in U6.4
> format
> 
> DSC parameter bits_per_pixel is stored in U6.4 format.
> The 4 bits represent the fractional part of the bpp.
> Currently we use compressed_bpp member of dsc structure to store only the
> integral part of the bits_per_pixel.
> To store the full bits_per_pixel along with the fractional part,
> compressed_bpp is changed to store bpp in U6.4 formats. Intergral part is
> retrieved by simply right shifting the member compressed_bpp by 4.
> 
> v2:
> -Use to_bpp_int, to_bpp_frac_dec, to_bpp_x16 helpers while dealing  with
> compressed bpp. (Suraj) -Fix comment styling. (Suraj)
> 
> v3:
> -Add separate file for 6.4 fixed point helper(Jani, Nikula) -Add comment for
> magic values(Suraj)
> 
> v4:
> -Fix checkpatch warnings caused by renaming(Suraj)
> 
> v5:
> -Rebase.
> -Use existing helpers for conversion of bpp_int to bpp_x16  and vice versa.
> 

LGTM.
Reviewed-by: Suraj Kandpal 

> Signed-off-by: Ankit Nautiyal 
> Signed-off-by: Mitul Golani 
> Reviewed-by: Suraj Kandpal 
> Reviewed-by: Sui Jingfeng 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c| 10 +++
>  drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_bios.c |  4 +--
>  drivers/gpu/drm/i915/display/intel_cdclk.c|  5 ++--
>  drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
>  .../drm/i915/display/intel_display_types.h|  3 ++-
>  drivers/gpu/drm/i915/display/intel_dp.c   | 27 ++-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  2 +-
>  drivers/gpu/drm/i915/display/intel_link_bw.c  |  2 +-
>  drivers/gpu/drm/i915/display/intel_vdsc.c |  4 +--
>  10 files changed, 33 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index c4585e445198..481fcb650850 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -330,7 +330,7 @@ static int afe_clk(struct intel_encoder *encoder,
>   int bpp;
> 
>   if (crtc_state->dsc.compression_enable)
> - bpp = crtc_state->dsc.compressed_bpp;
> + bpp = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
>   else
>   bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
> @@ -860,7 +860,7 @@ gen11_dsi_set_transcoder_timings(struct
> intel_encoder *encoder,
>* compressed and non-compressed bpp.
>*/
>   if (crtc_state->dsc.compression_enable) {
> - mul = crtc_state->dsc.compressed_bpp;
> + mul = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
>   div = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
>   }
> 
> @@ -884,7 +884,7 @@ gen11_dsi_set_transcoder_timings(struct
> intel_encoder *encoder,
>   int bpp, line_time_us, byte_clk_period_ns;
> 
>   if (crtc_state->dsc.compression_enable)
> - bpp = crtc_state->dsc.compressed_bpp;
> + bpp = to_bpp_int(crtc_state-
> >dsc.compressed_bpp_x16);
>   else
>   bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
> @@ -1451,8 +1451,8 @@ static void gen11_dsi_get_timings(struct
> intel_encoder *encoder,
>   struct drm_display_mode *adjusted_mode =
>   _config->hw.adjusted_mode;
> 
> - if (pipe_config->dsc.compressed_bpp) {
> - int div = pipe_config->dsc.compressed_bpp;
> + if (pipe_config->dsc.compressed_bpp_x16) {
> + int div = to_bpp_int(pipe_config->dsc.compressed_bpp_x16);
>   int mul = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
>   adjusted_mode->crtc_htotal =
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 19605264a35c..aa93ccd6c2aa 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -528,7 +528,7 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
>   pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> - vdsc_bpp = crtc_state->dsc.compressed_bpp;
> + vdsc_bpp = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
>   cdclk = i915->display.cdclk.hw.cdclk;
>   /* fec= 0.972261, using rounding multiplier of 100 */
>   fec_coeff = 972261;
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 719fb550342b..2fd72b2fd109 100644
> ---

Re: [Intel-gfx] [PATCH 2/4] drm/i915: add vlv_pipe_to_phy() helper to replace DPIO_PHY()

2023-11-14 Thread Ville Syrjälä

On Mon, Nov 13, 2023 at 06:47:09PM +0200, Jani Nikula wrote:
> Add a helper with better typing and handing for bogus input, and better
> in line with vlv_dig_port_to_channel(), vlv_dig_port_to_phy(), and
> vlv_pipe_to_channel().
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_dpio_phy.c | 14 ++
>  drivers/gpu/drm/i915/display/intel_dpio_phy.h |  5 +
>  drivers/gpu/drm/i915/display/intel_pps.c  |  2 +-
>  drivers/gpu/drm/i915/i915_reg.h   |  2 --
>  drivers/gpu/drm/i915/vlv_sideband.c   |  6 --
>  5 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.c 
> b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> index 62b93d097e44..d6af46e33424 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.c
> @@ -666,6 +666,20 @@ enum dpio_phy vlv_dig_port_to_phy(struct 
> intel_digital_port *dig_port)
>   }
>  }
>  
> +enum dpio_phy vlv_pipe_to_phy(enum pipe pipe)
> +{
> + switch (pipe) {
> + default:
> + MISSING_CASE(pipe);
> + fallthrough;
> + case PIPE_A:
> + case PIPE_B:
> + return DPIO_PHY0;
> + case PIPE_C:
> + return DPIO_PHY1;
> + }
> +}
> +
>  enum dpio_channel vlv_pipe_to_channel(enum pipe pipe)
>  {
>   switch (pipe) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dpio_phy.h 
> b/drivers/gpu/drm/i915/display/intel_dpio_phy.h
> index 4d43dbbdf81c..9adc4e8c1738 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpio_phy.h
> +++ b/drivers/gpu/drm/i915/display/intel_dpio_phy.h
> @@ -44,6 +44,7 @@ u8 bxt_ddi_phy_get_lane_lat_optim_mask(struct intel_encoder 
> *encoder);
>  
>  enum dpio_channel vlv_dig_port_to_channel(struct intel_digital_port 
> *dig_port);
>  enum dpio_phy vlv_dig_port_to_phy(struct intel_digital_port *dig_port);
> +enum dpio_phy vlv_pipe_to_phy(enum pipe pipe);
>  enum dpio_channel vlv_pipe_to_channel(enum pipe pipe);
>  
>  void chv_set_phy_signal_level(struct intel_encoder *encoder,
> @@ -116,6 +117,10 @@ static inline enum dpio_phy vlv_dig_port_to_phy(struct 
> intel_digital_port *dig_p
>  {
>   return DPIO_PHY0;
>  }
> +static inline enum dpio_phy vlv_pipe_to_phy(enum pipe pipe)
> +{
> + return DPIO_PHY0;
> +}
>  static inline enum dpio_channel vlv_pipe_to_channel(enum pipe pipe)
>  {
>   return DPIO_CH0;
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c 
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 73f0f1714b37..a8fa3a20990e 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -90,7 +90,7 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   enum pipe pipe = intel_dp->pps.pps_pipe;
>   bool pll_enabled, release_cl_override = false;
> - enum dpio_phy phy = DPIO_PHY(pipe);
> + enum dpio_phy phy = vlv_pipe_to_phy(pipe);
>   enum dpio_channel ch = vlv_pipe_to_channel(pipe);
>   u32 DP;
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 135e8d8dbdf0..27dc903f0553 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -195,8 +195,6 @@
>  #define  DPIO_SFR_BYPASS (1 << 1)
>  #define  DPIO_CMNRST (1 << 0)
>  
> -#define DPIO_PHY(pipe)   ((pipe) >> 1)
> -
>  /*
>   * Per pipe/PLL DPIO regs
>   */
> diff --git a/drivers/gpu/drm/i915/vlv_sideband.c 
> b/drivers/gpu/drm/i915/vlv_sideband.c
> index b98dec3ad817..f7df55217845 100644
> --- a/drivers/gpu/drm/i915/vlv_sideband.c
> +++ b/drivers/gpu/drm/i915/vlv_sideband.c
> @@ -229,7 +229,8 @@ static u32 vlv_dpio_phy_iosf_port(struct drm_i915_private 
> *i915, enum dpio_phy p
>  
>  u32 vlv_dpio_read(struct drm_i915_private *i915, enum pipe pipe, int reg)
>  {
> - u32 port = vlv_dpio_phy_iosf_port(i915, DPIO_PHY(pipe));
> + enum dpio_phy phy = vlv_pipe_to_phy(pipe);
> + u32 port = vlv_dpio_phy_iosf_port(i915, phy);
>   u32 val = 0;
>  
>   vlv_sideband_rw(i915, DPIO_DEVFN, port, SB_MRD_NP, reg, );
> @@ -248,7 +249,8 @@ u32 vlv_dpio_read(struct drm_i915_private *i915, enum 
> pipe pipe, int reg)
>  void vlv_dpio_write(struct drm_i915_private *i915,
>   enum pipe pipe, int reg, u32 val)
>  {
> - u32 port = vlv_dpio_phy_iosf_port(i915, DPIO_PHY(pipe));
> + enum dpio_phy phy = vlv_pipe_to_phy(pipe);
> + u32 port = vlv_dpio_phy_iosf_port(i915, phy);
>  
>   vlv_sideband_rw(i915, DPIO_DEVFN, port, SB_MWR_NP, reg, );
>  }
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 1/4] drm/i915: move *_crtc_clock_get() to intel_dpll.c

2023-11-14 Thread Ville Syrjälä

On Mon, Nov 13, 2023 at 06:47:08PM +0200, Jani Nikula wrote:
> Considering what the functions do, intel_dpll.c is a more suitable
> location, and lets us make some functions static while at it.
> 
> This also means intel_display.c no longer does any DPIO access.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_display.c  | 171 -
>  drivers/gpu/drm/i915/display/intel_display.h  |   2 -
>  drivers/gpu/drm/i915/display/intel_dpll.c | 175 +-
>  drivers/gpu/drm/i915/display/intel_dpll.h |   9 +-
>  .../gpu/drm/i915/display/intel_pch_display.c  |   1 +
>  5 files changed, 181 insertions(+), 177 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3effafcbb411..09056232483c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -73,7 +73,6 @@
>  #include "intel_dp.h"
>  #include "intel_dp_link_training.h"
>  #include "intel_dp_mst.h"
> -#include "intel_dpio_phy.h"
>  #include "intel_dpll.h"
>  #include "intel_dpll_mgr.h"
>  #include "intel_dpt.h"
> @@ -2859,67 +2858,6 @@ static void i9xx_get_pfit_config(struct 
> intel_crtc_state *crtc_state)
>   intel_de_read(dev_priv, PFIT_PGM_RATIOS);
>  }
>  
> -static void vlv_crtc_clock_get(struct intel_crtc *crtc,
> -struct intel_crtc_state *pipe_config)
> -{
> - struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - enum pipe pipe = crtc->pipe;
> - struct dpll clock;
> - u32 mdiv;
> - int refclk = 10;
> -
> - /* In case of DSI, DPLL will not be used */
> - if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
> - return;
> -
> - vlv_dpio_get(dev_priv);
> - mdiv = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW3(pipe));
> - vlv_dpio_put(dev_priv);
> -
> - clock.m1 = (mdiv >> DPIO_M1DIV_SHIFT) & 7;
> - clock.m2 = mdiv & DPIO_M2DIV_MASK;
> - clock.n = (mdiv >> DPIO_N_SHIFT) & 0xf;
> - clock.p1 = (mdiv >> DPIO_P1_SHIFT) & 7;
> - clock.p2 = (mdiv >> DPIO_P2_SHIFT) & 0x1f;
> -
> - pipe_config->port_clock = vlv_calc_dpll_params(refclk, );
> -}
> -
> -static void chv_crtc_clock_get(struct intel_crtc *crtc,
> -struct intel_crtc_state *pipe_config)
> -{
> - struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - enum pipe pipe = crtc->pipe;
> - enum dpio_channel port = vlv_pipe_to_channel(pipe);
> - struct dpll clock;
> - u32 cmn_dw13, pll_dw0, pll_dw1, pll_dw2, pll_dw3;
> - int refclk = 10;
> -
> - /* In case of DSI, DPLL will not be used */
> - if ((pipe_config->dpll_hw_state.dpll & DPLL_VCO_ENABLE) == 0)
> - return;
> -
> - vlv_dpio_get(dev_priv);
> - cmn_dw13 = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW13(port));
> - pll_dw0 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW0(port));
> - pll_dw1 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW1(port));
> - pll_dw2 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW2(port));
> - pll_dw3 = vlv_dpio_read(dev_priv, pipe, CHV_PLL_DW3(port));
> - vlv_dpio_put(dev_priv);
> -
> - clock.m1 = (pll_dw1 & 0x7) == DPIO_CHV_M1_DIV_BY_2 ? 2 : 0;
> - clock.m2 = (pll_dw0 & 0xff) << 22;
> - if (pll_dw3 & DPIO_CHV_FRAC_DIV_EN)
> - clock.m2 |= pll_dw2 & 0x3f;
> - clock.n = (pll_dw1 >> DPIO_CHV_N_DIV_SHIFT) & 0xf;
> - clock.p1 = (cmn_dw13 >> DPIO_CHV_P1_DIV_SHIFT) & 0x7;
> - clock.p2 = (cmn_dw13 >> DPIO_CHV_P2_DIV_SHIFT) & 0x1f;
> -
> - pipe_config->port_clock = chv_calc_dpll_params(refclk, );
> -}
> -
>  static enum intel_output_format
>  bdw_get_pipe_misc_output_format(struct intel_crtc *crtc)
>  {
> @@ -3840,115 +3778,6 @@ bool intel_crtc_get_pipe_config(struct 
> intel_crtc_state *crtc_state)
>   return true;
>  }
>  
> -static int i9xx_pll_refclk(struct drm_device *dev,
> -const struct intel_crtc_state *pipe_config)
> -{
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - u32 dpll = pipe_config->dpll_hw_state.dpll;
> -
> - if ((dpll & PLL_REF_INPUT_MASK) == PLLB_REF_INPUT_SPREADSPECTRUMIN)
> - return dev_priv->display.vbt.lvds_ssc_freq;
> - else if (HAS_PCH_SPLIT(dev_priv))
> - return 12;
> - else if (DISPLAY_VER(dev_priv) != 2)
> - return 96000;
> - else
> - return 48000;
> -}
> -
> -/* Returns the clock of the currently programmed mode of the given pipe. */
> -void i9xx_crtc_clock_get(struct intel_crtc *crtc,
> -  struct intel_crtc_state *pipe_config)
> -{
> - struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - u32 dpll = pipe_config->dpll_hw_state.dpll;
> - u32 fp;
> - struct

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: Account for channel coding efficiency on UHBR links

2023-11-14 Thread Jani Nikula

On Mon, 13 Nov 2023, Imre Deak  wrote:
> Apply the correct BW allocation overhead and channel coding efficiency
> on UHBR link rates, similarly to DP1.4 link rates.
>
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3effafcbb411a..24aebdb715e7d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2398,16 +2398,6 @@ add_bw_alloc_overhead(int link_clock, int bw_overhead,
>   int ch_coding_efficiency =
>   drm_dp_bw_channel_coding_efficiency(is_uhbr);

Why do we have this and intel_dp_max_data_rate() separately?

BR,
Jani.


>  
> - /*
> -  * TODO: adjust for actual UHBR channel coding efficiency and BW
> -  * overhead.
> -  */
> - if (is_uhbr) {
> - *data_m = pixel_data_rate;
> - *data_n = link_data_rate * 8 / 10;
> - return;
> - }
> -
>   *data_m = DIV_ROUND_UP_ULL(mul_u32_u32(pixel_data_rate, bw_overhead),
>  100);
>   *data_n = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_data_rate, 
> ch_coding_efficiency),

-- 
Jani Nikula, Intel

1 2 >

1 - 100 of 108 matches

Mail list logo