Re: [Intel-gfx] [PATCH 03/11] drm/i915/mst: Read out FEC state

[Luca Coelho]

On Tue, 2023-05-02 at 17:38 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> The MST codepath is missing FEC readout. Add it.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 55f36d9d509c..41cfa28166e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3763,6 +3763,11 @@ static void intel_ddi_read_func_ctl(struct 
> intel_encoder *encoder,
>   intel_cpu_transcoder_get_m1_n1(crtc, cpu_transcoder,
>  &pipe_config->dp_m_n);
>  
> + if (DISPLAY_VER(dev_priv) >= 11)
> + pipe_config->fec_enable =
> + intel_de_read(dev_priv,
> +   dp_tp_ctl_reg(encoder, 
> pipe_config)) & DP_TP_CTL_FEC_ENABLE;
> +
>   pipe_config->infoframes.enable |=
>   intel_hdmi_infoframes_enabled(encoder, pipe_config);
>   break;

LGTM.

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Turn off the timer to sample frequencies when GT is parked

[Tvrtko Ursulin]

On 24/05/2023 22:46, Dixit, Ashutosh wrote:

On Wed, 24 May 2023 02:12:31 -0700, Andrzej Hajda wrote:




Hi Andrzej,


On 23.05.2023 17:19, Ashutosh Dixit wrote:

pmu_needs_timer() keeps the timer running even when GT is parked,
ostensibly to sample requested/actual frequencies. However
frequency_sample() has the following:

/* Report 0/0 (actual/requested) frequency while parked. */
if (!intel_gt_pm_get_if_awake(gt))
return;

The above code prevents frequencies to be sampled while the GT is
parked. So we might as well turn off the sampling timer itself in this
case and save CPU cycles/power.

v2: Instead of turning freq bits off, return false, since no counters will
  run after this change when GT is parked (Tvrtko)

Signed-off-by: Ashutosh Dixit 
Reviewed-by: Tvrtko Ursulin 
---
   drivers/gpu/drm/i915/i915_pmu.c | 12 +---
   1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index a814583e19fd7..b47d890d4ada1 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -144,6 +144,10 @@ static bool pmu_needs_timer(struct i915_pmu *pmu, bool 
gpu_active)
struct drm_i915_private *i915 = container_of(pmu, typeof(*i915), pmu);
u32 enable;
   +/* When GPU is idle, at present no counters need to run */
+   if (!gpu_active)
+   return false;
+


What is then purpose of calling pmu_needs_timer with 2nd arg false?
Why not just replace all occurrences of pmu_needs_timer(.., false) with
false? And remove the 2nd argument.


OK, this didn't seem unreasonable so I went ahead and made this change in
Patch v3. Copying Tvrtko too in case he prefers v2 for any reason. Please
review.


It is all fine by me (the latest version and all)!

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Fix FEC pipe A vs. DDI A mixup

[Luca Coelho]

On Tue, 2023-05-02 at 17:38 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> On pre-TGL FEC is a port level feature, not a transcoder
> level features, and it's DDI A which doesn't have it, not
> trancodere A.

A couple of typos: "level feature" and "transcoder A".


>  Check for the correct thing when determining
> whether FEC is supported or not.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4361c1ac65c3..b27b4fb71ed7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1212,13 +1212,13 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, 
> int port_clock,
>  static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp,
>const struct intel_crtc_state 
> *pipe_config)
>  {
> + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>  
> - /* On TGL, FEC is supported on all Pipes */
>   if (DISPLAY_VER(dev_priv) >= 12)
>   return true;
>  
> - if (DISPLAY_VER(dev_priv) == 11 && pipe_config->cpu_transcoder != 
> TRANSCODER_A)
> + if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A)
>   return true;
>  
>   return false;

Other than that, looks good:

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH 05/11] drm/i915: Check lane count when determining FEC support

[Luca Coelho]

On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> ICL doesn't support FEC with a x1 DP link. Make sure
> we don't try to enable FEC in such cases.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index b27b4fb71ed7..9ac199444155 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1218,7 +1218,8 @@ static bool intel_dp_source_supports_fec(struct 
> intel_dp *intel_dp,
>   if (DISPLAY_VER(dev_priv) >= 12)
>   return true;
>  
> - if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A)
> + if (DISPLAY_VER(dev_priv) == 11 &&
> + encoder->port != PORT_A && pipe_config->lane_count != 1)
>   return true;
>  
>   return false;
> @@ -1234,7 +1235,7 @@ static bool intel_dp_supports_fec(struct intel_dp 
> *intel_dp,
>  static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state)
>  {
> - if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP) && 
> !crtc_state->fec_enable)
> + if (!intel_dp_is_edp(intel_dp) && !crtc_state->fec_enable)

I'm probably missing something, but this change...


>   return false;
>  
>   return intel_dsc_source_support(crtc_state) &&
> @@ -1580,15 +1581,6 @@ int intel_dp_dsc_compute_config(struct intel_dp 
> *intel_dp,
>   int pipe_bpp;
>   int ret;
>  
> - pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
> - intel_dp_supports_fec(intel_dp, pipe_config);
> -
> - if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> - return -EINVAL;
> -
> - if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
> - return -EINVAL;
> -
>   if (compute_pipe_bpp)
>   pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, 
> conn_state->max_requested_bpc);
>   else
> @@ -1615,6 +1607,15 @@ int intel_dp_dsc_compute_config(struct intel_dp 
> *intel_dp,
>   pipe_config->port_clock = limits->max_rate;
>   pipe_config->lane_count = limits->max_lane_count;
>  
> + pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
> + intel_dp_supports_fec(intel_dp, pipe_config);
> +
> + if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> + return -EINVAL;
> +
> + if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
> + return -EINVAL;
> +
>   if (intel_dp_is_edp(intel_dp)) {
>   pipe_config->dsc.compressed_bpp =
>   min_t(u16, 
> drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,

...and this code move are not explained in the commit message? How are
they related?

--
Cheers,
Luca.

[Intel-gfx] [PATCH v3 0/5] Expose RPS thresholds in sysfs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

>From patch 4:

User feedback indicates significant performance gains are possible in
specific games with non default RPS up/down thresholds.

Expose these tunables via sysfs which will allow users to achieve best
performance when running games and best power efficiency elsewhere.

Note this patch supports non GuC based platforms only.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/8389

Issue 8389 suggests 10-15% performance gains are possible with tweaked
thresholds.

One question is are we able to find a "one size fits all" values.

However regardless of that, given we already expose frequency controls in sysfs
with the same reasoning of allowing system owners explicit control if so wanted,
I think exposing the thresholds can be equally justified.

v2:
 * Hopefully fixed the debug build issue.
 * Re-program the hw registers on change too!

v3:
 * Added a patch which captures the thresholds in error state, to account for
   any potential instability which may be caused by moving away from defaults.
 * Fixed one checkpatch warning.

Test-with: 20230523105139.626772-1-tvrtko.ursu...@linux.intel.com

Tvrtko Ursulin (5):
  drm/i915: Move setting of rps thresholds to init
  drm/i915: Record default rps threshold values
  drm/i915: Add helpers for managing rps thresholds
  drm/i915: Expose RPS thresholds in sysfs
  drm/i915: Include RPS threshold in error state

 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 108 
 drivers/gpu/drm/i915/gt/intel_gt_types.h|   3 +
 drivers/gpu/drm/i915/gt/intel_rps.c |  83 +--
 drivers/gpu/drm/i915/gt/intel_rps.h |   4 +
 drivers/gpu/drm/i915/i915_gpu_error.c   |   5 +
 drivers/gpu/drm/i915/i915_gpu_error.h   |   5 +
 6 files changed, 197 insertions(+), 11 deletions(-)

-- 
2.39.2

[Intel-gfx] [PATCH 1/5] drm/i915: Move setting of rps thresholds to init

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Since 36d516be867c ("drm/i915/gt: Switch to manual evaluation of RPS")
thresholds are invariant so lets move their setting to init time.

Signed-off-by: Tvrtko Ursulin 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index e68a99205599..791097eb9bfd 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -671,7 +671,6 @@ static void rps_set_power(struct intel_rps *rps, int 
new_power)
 {
struct intel_gt *gt = rps_to_gt(rps);
struct intel_uncore *uncore = gt->uncore;
-   u32 threshold_up = 0, threshold_down = 0; /* in % */
u32 ei_up = 0, ei_down = 0;
 
lockdep_assert_held(&rps->power.mutex);
@@ -679,9 +678,6 @@ static void rps_set_power(struct intel_rps *rps, int 
new_power)
if (new_power == rps->power.mode)
return;
 
-   threshold_up = 95;
-   threshold_down = 85;
-
/* Note the units here are not exactly 1us, but 1280ns. */
switch (new_power) {
case LOW_POWER:
@@ -708,17 +704,22 @@ static void rps_set_power(struct intel_rps *rps, int 
new_power)
 
GT_TRACE(gt,
 "changing power mode [%d], up %d%% @ %dus, down %d%% @ %dus\n",
-new_power, threshold_up, ei_up, threshold_down, ei_down);
+new_power,
+rps->power.up_threshold, ei_up,
+rps->power.down_threshold, ei_down);
 
set(uncore, GEN6_RP_UP_EI,
intel_gt_ns_to_pm_interval(gt, ei_up * 1000));
set(uncore, GEN6_RP_UP_THRESHOLD,
-   intel_gt_ns_to_pm_interval(gt, ei_up * threshold_up * 10));
+   intel_gt_ns_to_pm_interval(gt,
+  ei_up * rps->power.up_threshold * 10));
 
set(uncore, GEN6_RP_DOWN_EI,
intel_gt_ns_to_pm_interval(gt, ei_down * 1000));
set(uncore, GEN6_RP_DOWN_THRESHOLD,
-   intel_gt_ns_to_pm_interval(gt, ei_down * threshold_down * 10));
+   intel_gt_ns_to_pm_interval(gt,
+  ei_down *
+  rps->power.down_threshold * 10));
 
set(uncore, GEN6_RP_CONTROL,
(GRAPHICS_VER(gt->i915) > 9 ? 0 : GEN6_RP_MEDIA_TURBO) |
@@ -730,8 +731,6 @@ static void rps_set_power(struct intel_rps *rps, int 
new_power)
 
 skip_hw_write:
rps->power.mode = new_power;
-   rps->power.up_threshold = threshold_up;
-   rps->power.down_threshold = threshold_down;
 }
 
 static void gen6_rps_set_thresholds(struct intel_rps *rps, u8 val)
@@ -1557,10 +1556,12 @@ void intel_rps_enable(struct intel_rps *rps)
return;
 
GT_TRACE(rps_to_gt(rps),
-"min:%x, max:%x, freq:[%d, %d]\n",
+"min:%x, max:%x, freq:[%d, %d], thresholds:[%u, %u]\n",
 rps->min_freq, rps->max_freq,
 intel_gpu_freq(rps, rps->min_freq),
-intel_gpu_freq(rps, rps->max_freq));
+intel_gpu_freq(rps, rps->max_freq),
+rps->power.up_threshold,
+rps->power.down_threshold);
 
GEM_BUG_ON(rps->max_freq < rps->min_freq);
GEM_BUG_ON(rps->idle_freq > rps->max_freq);
@@ -2013,6 +2014,10 @@ void intel_rps_init(struct intel_rps *rps)
}
}
 
+   /* Set default thresholds in % */
+   rps->power.up_threshold = 95;
+   rps->power.down_threshold = 85;
+
/* Finally allow us to boost to max by default */
rps->boost_freq = rps->max_freq;
rps->idle_freq = rps->min_freq;
-- 
2.39.2

[Intel-gfx] [PATCH 5/5] drm/i915: Include RPS threshold in error state

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Now that we allow them to be modified, lets include them in the error
state so it is visible when they have been modified in GPU hang triage.

Signed-off-by: Tvrtko Ursulin 
Cc: Rodrigo Vivi 
Cc: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 5 +
 drivers/gpu/drm/i915/i915_gpu_error.h | 5 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index ec368e700235..f9733c159b9b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -740,6 +740,8 @@ static void err_print_gt_global_nonguc(struct 
drm_i915_error_state_buf *m,
err_printf(m, "GT awake: %s\n", str_yes_no(gt->awake));
err_printf(m, "CS timestamp frequency: %u Hz, %d ns\n",
   gt->clock_frequency, gt->clock_period_ns);
+   err_printf(m, "RPS thresholds up/down: %u/%u %%\n",
+  gt->rps.up_threshold, gt->rps.down_threshold);
err_printf(m, "EIR: 0x%08x\n", gt->eir);
err_printf(m, "PGTBL_ER: 0x%08x\n", gt->pgtbl_er);
 
@@ -2025,6 +2027,9 @@ intel_gt_coredump_alloc(struct intel_gt *gt, gfp_t gfp, 
u32 dump_flags)
gc->_gt = gt;
gc->awake = intel_gt_pm_is_awake(gt);
 
+   gc->rps.up_threshold = gt->rps.power.up_threshold;
+   gc->rps.down_threshold = gt->rps.power.down_threshold;
+
gt_record_display_regs(gc);
gt_record_global_nonguc_regs(gc);
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index a78c061ce26f..6d2996ad2abb 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -140,6 +140,11 @@ struct intel_gt_coredump {
bool awake;
bool simulated;
 
+   struct {
+   u8 up_threshold;
+   u8 down_threshold;
+   } rps;
+
struct intel_gt_info info;
 
/* Generic register state */
-- 
2.39.2

[Intel-gfx] [PATCH 3/5] drm/i915: Add helpers for managing rps thresholds

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

In preparation for exposing via sysfs add helpers for managing rps
thresholds.

v2:
 * Force sw and hw re-programming on threshold change.

Signed-off-by: Tvrtko Ursulin 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 54 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  4 +++
 2 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 333abc8f7ecb..afde601a6111 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -16,7 +16,9 @@
 #include "intel_gt.h"
 #include "intel_gt_clock_utils.h"
 #include "intel_gt_irq.h"
+#include "intel_gt_pm.h"
 #include "intel_gt_pm_irq.h"
+#include "intel_gt_print.h"
 #include "intel_gt_regs.h"
 #include "intel_mchbar_regs.h"
 #include "intel_pcode.h"
@@ -2574,6 +2576,58 @@ int intel_rps_set_min_frequency(struct intel_rps *rps, 
u32 val)
return set_min_freq(rps, val);
 }
 
+u8 intel_rps_get_up_threshold(struct intel_rps *rps)
+{
+   return rps->power.up_threshold;
+}
+
+static int rps_set_threshold(struct intel_rps *rps, u8 *threshold, u8 val)
+{
+   int ret;
+
+   if (val > 100)
+   return -EINVAL;
+
+   ret = mutex_lock_interruptible(&rps->lock);
+   if (ret)
+   return ret;
+
+   if (*threshold == val)
+   goto out_unlock;
+
+   *threshold = val;
+
+   /* Force reset. */
+   rps->last_freq = -1;
+   mutex_lock(&rps->power.mutex);
+   rps->power.mode = -1;
+   mutex_unlock(&rps->power.mutex);
+
+   intel_rps_set(rps, clamp(rps->cur_freq,
+rps->min_freq_softlimit,
+rps->max_freq_softlimit));
+
+out_unlock:
+   mutex_unlock(&rps->lock);
+
+   return ret;
+}
+
+int intel_rps_set_up_threshold(struct intel_rps *rps, u8 threshold)
+{
+   return rps_set_threshold(rps, &rps->power.up_threshold, threshold);
+}
+
+u8 intel_rps_get_down_threshold(struct intel_rps *rps)
+{
+   return rps->power.down_threshold;
+}
+
+int intel_rps_set_down_threshold(struct intel_rps *rps, u8 threshold)
+{
+   return rps_set_threshold(rps, &rps->power.down_threshold, threshold);
+}
+
 static void intel_rps_set_manual(struct intel_rps *rps, bool enable)
 {
struct intel_uncore *uncore = rps_to_uncore(rps);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index a3fa987aa91f..92fb01f5a452 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -37,6 +37,10 @@ void intel_rps_mark_interactive(struct intel_rps *rps, bool 
interactive);
 
 int intel_gpu_freq(struct intel_rps *rps, int val);
 int intel_freq_opcode(struct intel_rps *rps, int val);
+u8 intel_rps_get_up_threshold(struct intel_rps *rps);
+int intel_rps_set_up_threshold(struct intel_rps *rps, u8 threshold);
+u8 intel_rps_get_down_threshold(struct intel_rps *rps);
+int intel_rps_set_down_threshold(struct intel_rps *rps, u8 threshold);
 u32 intel_rps_read_actual_frequency(struct intel_rps *rps);
 u32 intel_rps_read_actual_frequency_fw(struct intel_rps *rps);
 u32 intel_rps_get_requested_frequency(struct intel_rps *rps);
-- 
2.39.2

[Intel-gfx] [PATCH 2/5] drm/i915: Record default rps threshold values

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Record the default values as preparation for exposing the sysfs controls.

Signed-off-by: Tvrtko Ursulin 
Cc: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
 drivers/gpu/drm/i915/gt/intel_rps.c  | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f08c2556aa25..1b22d7a50665 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -83,6 +83,9 @@ enum intel_submission_method {
 struct gt_defaults {
u32 min_freq;
u32 max_freq;
+
+   u8 rps_up_threshold;
+   u8 rps_down_threshold;
 };
 
 enum intel_gt_type {
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 791097eb9bfd..333abc8f7ecb 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2016,7 +2016,9 @@ void intel_rps_init(struct intel_rps *rps)
 
/* Set default thresholds in % */
rps->power.up_threshold = 95;
+   rps_to_gt(rps)->defaults.rps_up_threshold = rps->power.up_threshold;
rps->power.down_threshold = 85;
+   rps_to_gt(rps)->defaults.rps_down_threshold = rps->power.down_threshold;
 
/* Finally allow us to boost to max by default */
rps->boost_freq = rps->max_freq;
-- 
2.39.2

[Intel-gfx] [PATCH 4/5] drm/i915: Expose RPS thresholds in sysfs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

User feedback indicates significant performance gains are possible in
specific games with non default RPS up/down thresholds.

Expose these tunables via sysfs which will allow users to achieve best
performance when running games and best power efficiency elsewhere.

Note this patch supports non GuC based platforms only.

v2:
 * Make checkpatch happy.

Signed-off-by: Tvrtko Ursulin 
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8389
Cc: Rodrigo Vivi 
Acked-by: Rodrigo Vivi 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 108 
 1 file changed, 108 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index ee2b44f896a2..f0dea54880af 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -700,6 +700,80 @@ static const struct attribute *media_perf_power_attrs[] = {
NULL
 };
 
+static ssize_t
+rps_up_threshold_pct_show(struct kobject *kobj, struct kobj_attribute *attr,
+ char *buf)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_rps *rps = >->rps;
+
+   return sysfs_emit(buf, "%u\n", intel_rps_get_up_threshold(rps));
+}
+
+static ssize_t
+rps_up_threshold_pct_store(struct kobject *kobj, struct kobj_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_rps *rps = >->rps;
+   int ret;
+   u8 val;
+
+   ret = kstrtou8(buf, 10, &val);
+   if (ret)
+   return ret;
+
+   ret = intel_rps_set_up_threshold(rps, val);
+
+   return ret == 0 ? count : ret;
+}
+
+static struct kobj_attribute rps_up_threshold_pct =
+   __ATTR(rps_up_threshold_pct,
+  0664,
+  rps_up_threshold_pct_show,
+  rps_up_threshold_pct_store);
+
+static ssize_t
+rps_down_threshold_pct_show(struct kobject *kobj, struct kobj_attribute *attr,
+   char *buf)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_rps *rps = >->rps;
+
+   return sysfs_emit(buf, "%u\n", intel_rps_get_down_threshold(rps));
+}
+
+static ssize_t
+rps_down_threshold_pct_store(struct kobject *kobj, struct kobj_attribute *attr,
+const char *buf, size_t count)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+   struct intel_rps *rps = >->rps;
+   int ret;
+   u8 val;
+
+   ret = kstrtou8(buf, 10, &val);
+   if (ret)
+   return ret;
+
+   ret = intel_rps_set_down_threshold(rps, val);
+
+   return ret == 0 ? count : ret;
+}
+
+static struct kobj_attribute rps_down_threshold_pct =
+   __ATTR(rps_down_threshold_pct,
+  0664,
+  rps_down_threshold_pct_show,
+  rps_down_threshold_pct_store);
+
+static const struct attribute * const gen6_gt_rps_attrs[] = {
+   &rps_up_threshold_pct.attr,
+   &rps_down_threshold_pct.attr,
+   NULL
+};
+
 static ssize_t
 default_min_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr, 
char *buf)
 {
@@ -722,9 +796,37 @@ default_max_freq_mhz_show(struct kobject *kobj, struct 
kobj_attribute *attr, cha
 static struct kobj_attribute default_max_freq_mhz =
 __ATTR(rps_max_freq_mhz, 0444, default_max_freq_mhz_show, NULL);
 
+static ssize_t
+default_rps_up_threshold_pct_show(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ char *buf)
+{
+   struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+   return sysfs_emit(buf, "%u\n", gt->defaults.rps_up_threshold);
+}
+
+static struct kobj_attribute default_rps_up_threshold_pct =
+__ATTR(rps_up_threshold_pct, 0444, default_rps_up_threshold_pct_show, NULL);
+
+static ssize_t
+default_rps_down_threshold_pct_show(struct kobject *kobj,
+   struct kobj_attribute *attr,
+   char *buf)
+{
+   struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+   return sysfs_emit(buf, "%u\n", gt->defaults.rps_down_threshold);
+}
+
+static struct kobj_attribute default_rps_down_threshold_pct =
+__ATTR(rps_down_threshold_pct, 0444, default_rps_down_threshold_pct_show, 
NULL);
+
 static const struct attribute * const rps_defaults_attrs[] = {
&default_min_freq_mhz.attr,
&default_max_freq_mhz.attr,
+   &default_rps_up_threshold_pct.attr,
+   &default_rps_down_threshold_pct.attr,
NULL
 };
 
@@ -752,6 +854,12 @@ static int intel_sysfs_rps_init(struct intel_gt *gt, 
struct kobject *kobj)
if (IS_VALLEYVIEW(gt->i915) || IS_CHERRYVIEW(gt->i915))
ret = sysfs_create_file(kobj, vlv_attr);
 
+   if (is_object_gt(kobj) && 

Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation

[Tvrtko Ursulin]

On 24/05/2023 21:02, fei.y...@intel.com wrote:

From: Fei Yang 

This series introduce a new extension for GEM_CREATE,
1. end support for set caching ioctl [PATCH 1/2]
2. add set_pat extension for gem_create [PATCH 2/2]

v2: drop one patch that was merged separately
 commit 341ad0e8e254 ("drm/i915/mtl: Add PTE encode function")
v3: rebased on https://patchwork.freedesktop.org/series/117082/
v4: fix missing unlock introduced in v3, and
 solve a rebase conflict
v5: replace obj->cache_level with pat_set_by_user,
 fix i915_cache_level_str() for legacy platforms.
v6: rebased on https://patchwork.freedesktop.org/series/117480/
v7: rebased on https://patchwork.freedesktop.org/series/117528/
v8: dropped the two dependent patches that has been merged
 separately. Add IGT link and Tested-by (MESA).
v9: addressing comments (Andi)
v10: acked-by and tested-by MESA
v11: drop "end support for set caching ioctl" (merged)
  remove tools/include/uapi/drm/i915_drm.h
v12: drop Bspec reference in comment. add to commit message instead

Fei Yang (1):
   drm/i915: Allow user to set cache at BO creation

  drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
  drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
  include/uapi/drm/i915_drm.h| 41 ++
  3 files changed, 83 insertions(+)



Do you also have a Test-with: run against the new IGT somewhere?

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 06/11] drm/i915: Fix FEC state dump

[Luca Coelho]

On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Stop dumping state while reading it out. We have a proper
> place for that stuff.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  .../gpu/drm/i915/display/intel_crtc_state_dump.c|  2 ++
>  drivers/gpu/drm/i915/display/intel_ddi.c| 13 +++--
>  2 files changed, 5 insertions(+), 10 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 0cdcaa49656f..91242ffe0768 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> @@ -257,6 +257,8 @@ void intel_crtc_state_dump(const struct intel_crtc_state 
> *pipe_config,
>   intel_dump_m_n_config(pipe_config, "dp m2_n2",
> pipe_config->lane_count,
> &pipe_config->dp_m2_n2);
> + drm_dbg_kms(&i915->drm, "fec: %s\n",
> + str_enabled_disabled(pipe_config->fec_enable));
>   }
>  
>   drm_dbg_kms(&i915->drm, "framestart delay: %d, MSA timing delay: %d\n",
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 41cfa28166e4..4246133950fd 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3725,17 +3725,10 @@ static void intel_ddi_read_func_ctl(struct 
> intel_encoder *encoder,
>   intel_cpu_transcoder_get_m2_n2(crtc, cpu_transcoder,
>  &pipe_config->dp_m2_n2);
>  
> - if (DISPLAY_VER(dev_priv) >= 11) {
> - i915_reg_t dp_tp_ctl = dp_tp_ctl_reg(encoder, 
> pipe_config);
> -
> + if (DISPLAY_VER(dev_priv) >= 11)
>   pipe_config->fec_enable =
> - intel_de_read(dev_priv, dp_tp_ctl) & 
> DP_TP_CTL_FEC_ENABLE;
> -
> - drm_dbg_kms(&dev_priv->drm,
> - "[ENCODER:%d:%s] Fec status: %u\n",
> - encoder->base.base.id, encoder->base.name,
> - pipe_config->fec_enable);
> - }
> + intel_de_read(dev_priv,
> +   dp_tp_ctl_reg(encoder, 
> pipe_config)) & DP_TP_CTL_FEC_ENABLE;
>  
>   if (dig_port->lspcon.active && dig_port->dp.has_hdmi_sink)
>   pipe_config->infoframes.enable |=

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH 07/11] drm/i915: Split some long lines

[Luca Coelho]

On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Split some overly long lines.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_fdi.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

It doesn't matter much, but it would be nice to say where you're
splitting the long lines? If nothing else, it would at least make the
commit message more unique:

"drm/i915: Split some long lines in hsw_fdi_link_train()"

Other than this nitpick:

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Expose RPS thresholds in sysfs (rev3)

[Patchwork]

== Series Details ==

Series: Expose RPS thresholds in sysfs (rev3)
URL   : https://patchwork.freedesktop.org/series/117054/
State : warning

== Summary ==

Error: dim checkpatch failed
20c0f30d677d drm/i915: Move setting of rps thresholds to init
-:6: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 36d516be867c ("drm/i915/gt: 
Switch to manual evaluation of RPS")'
#6: 
Since 36d516be867c ("drm/i915/gt: Switch to manual evaluation of RPS")

total: 1 errors, 0 warnings, 0 checks, 73 lines checked
5c75b4a5bc5b drm/i915: Record default rps threshold values
31869ff1e371 drm/i915: Add helpers for managing rps thresholds
e4da8df22f11 drm/i915: Expose RPS thresholds in sysfs
d3cc1f5d3545 drm/i915: Include RPS threshold in error state

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Expose RPS thresholds in sysfs (rev3)

[Patchwork]

== Series Details ==

Series: Expose RPS thresholds in sysfs (rev3)
URL   : https://patchwork.freedesktop.org/series/117054/
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] [RESEND PATCH] drm/i915: constify pointers to hwmon_channel_info

[Jani Nikula]

On Thu, 11 May 2023, Krzysztof Kozlowski  wrote:
> Statically allocated array of pointers to hwmon_channel_info can be made
> const for safety.

Btw if you want to further make things const, the compound literals
defined by HWMON_CHANNEL_INFO() still end up mutable, even if they're
only referenced inline using a const pointer. If possible, would be nice
to add const there too.

BR,
Jani.

>
> Acked-by: Jani Nikula 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/i915/i915_hwmon.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 8e7dccc8d3a0..e99e8c97ef01 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -267,7 +267,7 @@ static const struct attribute_group *hwm_groups[] = {
>   NULL
>  };
>  
> -static const struct hwmon_channel_info *hwm_info[] = {
> +static const struct hwmon_channel_info * const hwm_info[] = {
>   HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
>   HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX | 
> HWMON_P_CRIT),
>   HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
> @@ -275,7 +275,7 @@ static const struct hwmon_channel_info *hwm_info[] = {
>   NULL
>  };
>  
> -static const struct hwmon_channel_info *hwm_gt_info[] = {
> +static const struct hwmon_channel_info * const hwm_gt_info[] = {
>   HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
>   NULL
>  };

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Assert that device info bitmasks have enough bits

[Jani Nikula]

On Wed, 24 May 2023, Lucas De Marchi  wrote:
> On Thu, May 11, 2023 at 07:55:30PM +0300, Ville Syrjälä wrote:
>>From: Ville Syrjälä 
>>
>>Sprinkle in some BUILD_BUG_ON()s to make sure some of
>>the bitmasks used in the device info have enough bits.
>>
>>Do we have a better place for this sort of stuff?
>
> it's being moved to display/, so I'd say the intel_display_device_info.c
> is a better place. What about using a static_assert() and leave them
> near the top of the file?

I'm afraid the whole series needs a rebase too.

BR,
Jani.

>
> Lucas De Marchi
>
>>
>>Signed-off-by: Ville Syrjälä 
>>---
>> drivers/gpu/drm/i915/intel_device_info.c | 4 
>> 1 file changed, 4 insertions(+)
>>
>>diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
>>b/drivers/gpu/drm/i915/intel_device_info.c
>>index bb10e8e78a94..ce257446b712 100644
>>--- a/drivers/gpu/drm/i915/intel_device_info.c
>>+++ b/drivers/gpu/drm/i915/intel_device_info.c
>>@@ -414,6 +414,10 @@ void intel_device_info_runtime_init(struct 
>>drm_i915_private *dev_priv)
>>  struct intel_runtime_info *runtime = RUNTIME_INFO(dev_priv);
>>  enum pipe pipe;
>>
>>+ BUILD_BUG_ON(BITS_PER_TYPE(runtime->pipe_mask) < I915_MAX_PIPES);
>>+ BUILD_BUG_ON(BITS_PER_TYPE(runtime->cpu_transcoder_mask) < 
>>I915_MAX_TRANSCODERS);
>>+ BUILD_BUG_ON(BITS_PER_TYPE(runtime->port_mask) < I915_MAX_PORTS);
>>+
>>  /* Wa_14011765242: adl-s A0,A1 */
>>  if (IS_ADLS_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A2))
>>  for_each_pipe(dev_priv, pipe)
>>-- 
>>2.39.3
>>

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] [PATCH] drm/i915/gsc: use system include style for drm headers

[Jani Nikula]

Use <> instead of "" for including headers from include/.

Fixes: 8a9bf29546a1 ("drm/i915/gsc: add initial support for GSC proxy")
Cc: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
index ebee0b5a2c1d..5f138de3c14f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
@@ -5,8 +5,8 @@
 
 #include 
 
-#include "drm/i915_component.h"
-#include "drm/i915_gsc_proxy_mei_interface.h"
+#include 
+#include 
 
 #include "gt/intel_gt.h"
 #include "gt/intel_gt_print.h"
-- 
2.39.2

Re: [Intel-gfx] [PATCH v2 08/11] drm/i915: Introduce crtc_state->enhanced_framing

[Luca Coelho]

On Wed, 2023-05-03 at 14:36 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Track DP enhanced framing properly in the crtc state instead
> of relying just on the cached DPCD everywhere, and hook it
> up into the state check and dump.
> 
> v2: Actually set enhanced_framing in .compute_config()
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/g4x_dp.c | 10 --
>  drivers/gpu/drm/i915/display/intel_crt.c  |  2 ++
>  drivers/gpu/drm/i915/display/intel_crtc_state_dump.c  |  5 +++--
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 11 +--
>  drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>  drivers/gpu/drm/i915/display/intel_display_types.h|  2 ++
>  drivers/gpu/drm/i915/display/intel_dp.c   |  3 +++
>  drivers/gpu/drm/i915/display/intel_dp_link_training.c |  2 +-
>  8 files changed, 29 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c 
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index 920d570f7594..534546ea7d0b 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -141,7 +141,7 @@ static void intel_dp_prepare(struct intel_encoder 
> *encoder,
>  
>   intel_de_rmw(dev_priv, TRANS_DP_CTL(crtc->pipe),
>TRANS_DP_ENH_FRAMING,
> -  drm_dp_enhanced_frame_cap(intel_dp->dpcd) ?
> +  pipe_config->enhanced_framing ?
>TRANS_DP_ENH_FRAMING : 0);
>   } else {
>   if (IS_G4X(dev_priv) && pipe_config->limited_color_range)
> @@ -153,7 +153,7 @@ static void intel_dp_prepare(struct intel_encoder 
> *encoder,
>   intel_dp->DP |= DP_SYNC_VS_HIGH;
>   intel_dp->DP |= DP_LINK_TRAIN_OFF;
>  
> - if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
> + if (pipe_config->enhanced_framing)
>   intel_dp->DP |= DP_ENHANCED_FRAMING;
>  
>   if (IS_CHERRYVIEW(dev_priv))
> @@ -351,6 +351,9 @@ static void intel_dp_get_config(struct intel_encoder 
> *encoder,
>   u32 trans_dp = intel_de_read(dev_priv,
>TRANS_DP_CTL(crtc->pipe));
>  
> + if (trans_dp & TRANS_DP_ENH_FRAMING)
> + pipe_config->enhanced_framing = true;
> +
>   if (trans_dp & TRANS_DP_HSYNC_ACTIVE_HIGH)
>   flags |= DRM_MODE_FLAG_PHSYNC;
>   else
> @@ -361,6 +364,9 @@ static void intel_dp_get_config(struct intel_encoder 
> *encoder,
>   else
>   flags |= DRM_MODE_FLAG_NVSYNC;
>   } else {
> + if (tmp & DP_ENHANCED_FRAMING)
> + pipe_config->enhanced_framing = true;
> +
>   if (tmp & DP_SYNC_HS_HIGH)
>   flags |= DRM_MODE_FLAG_PHSYNC;
>   else
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 13519f78cf9f..52af64aa9953 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -449,6 +449,8 @@ static int hsw_crt_compute_config(struct intel_encoder 
> *encoder,
>   /* FDI must always be 2.7 GHz */
>   pipe_config->port_clock = 135000 * 2;
>  
> + pipe_config->enhanced_framing = true;
> +

Just curious, why are you setting it to true by default here?

Otherwise, the changes look reasonable:

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH 09/11] drm/i915: Stop spamming the logs with PLL state

[Luca Coelho]

On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> encoder->get_config() is not the place where the state
> should be dumped. Get rid of the spam.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 51ae1aad7cc7..65e031ff740c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3863,11 +3863,9 @@ static void mtl_ddi_get_config(struct intel_encoder 
> *encoder,
>   crtc_state->port_clock = intel_mtl_tbt_calc_port_clock(encoder);
>   } else if (intel_is_c10phy(i915, phy)) {
>   intel_c10pll_readout_hw_state(encoder, 
> &crtc_state->cx0pll_state.c10);
> - intel_c10pll_dump_hw_state(i915, &crtc_state->cx0pll_state.c10);
>   crtc_state->port_clock = intel_c10pll_calc_port_clock(encoder, 
> &crtc_state->cx0pll_state.c10);
>   } else {
>   intel_c20pll_readout_hw_state(encoder, 
> &crtc_state->cx0pll_state.c20);
> - intel_c20pll_dump_hw_state(i915, &crtc_state->cx0pll_state.c20);
>   crtc_state->port_clock = intel_c20pll_calc_port_clock(encoder, 
> &crtc_state->cx0pll_state.c20);
>   }
>  

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Drop some redundant eDP checks

[Luca Coelho]

On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> There's no need to check for both eDP and fixed_mode when
> deciding whether to do the pfit calculations or not.
> 
> Signed-off-by: Ville Syrjälä 
> ---

It would be nice to explain _why_ this is not needed.  Is it because
fixed_mode is always eDP?

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Reduce combo PHY log spam

[Luca Coelho]

On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We always check whether combo PHYs need to be re-initialized
> after disabling DC states, which leads to log spam. Switch things
> around so that we only log something when we actually have to
> re-initialized a PHY.
> 
> The log spam was exacerbated by commit 41b4c7fe72b6 ("drm/i915:
> Disable DC states for all commits") since we now disable DC
> states far more often.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_combo_phy.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c 
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 922a6d87b553..ee843f2b1af1 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -114,10 +114,6 @@ static bool icl_verify_procmon_ref_values(struct 
> drm_i915_private *dev_priv,
>  
>   procmon = icl_get_procmon_ref_values(dev_priv, phy);
>  
> - drm_dbg_kms(&dev_priv->drm,
> - "Combo PHY %c Voltage/Process Info : %s\n",
> - phy_name(phy), procmon->name);
> -
>   ret = check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW1(phy),
>   (0xff << 16) | 0xff, procmon->dw1);
>   ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW9(phy),
> @@ -312,14 +308,17 @@ static void icl_combo_phys_init(struct drm_i915_private 
> *dev_priv)
>   enum phy phy;
>  
>   for_each_combo_phy(dev_priv, phy) {
> + const struct icl_procmon *procmon;
>   u32 val;
>  
> - if (icl_combo_phy_verify_state(dev_priv, phy)) {
> - drm_dbg(&dev_priv->drm,
> - "Combo PHY %c already enabled, won't reprogram 
> it.\n",
> - phy_name(phy));
> + if (icl_combo_phy_verify_state(dev_priv, phy))
>   continue;
> - }
> +
> + procmon = icl_get_procmon_ref_values(dev_priv, phy);
> +
> + drm_dbg(&dev_priv->drm,
> + "Initializing combo PHY %c (Voltage/Process Info : 
> %s)\n",
> + phy_name(phy), procmon->name);
>  
>   if (!has_phy_misc(dev_priv, phy))
>   goto skip_phy_misc;

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

Re: [Intel-gfx] [PATCH] drm/i915/gsc: use system include style for drm headers

[Luca Coelho]

On Thu, 2023-05-25 at 12:49 +0300, Jani Nikula wrote:
> Use <> instead of "" for including headers from include/.
> 
> Fixes: 8a9bf29546a1 ("drm/i915/gsc: add initial support for GSC proxy")
> Cc: Daniele Ceraolo Spurio 
> Cc: Alan Previn 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
> index ebee0b5a2c1d..5f138de3c14f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
> @@ -5,8 +5,8 @@
>  
>  #include 
>  
> -#include "drm/i915_component.h"
> -#include "drm/i915_gsc_proxy_mei_interface.h"
> +#include 
> +#include 
>  
>  #include "gt/intel_gt.h"
>  #include "gt/intel_gt_print.h"

Reviewed-by: Luca Coelho 

--
Cheers,
Luca.

[Intel-gfx] [PATCH] drm/i915: Fix the disabling sequence for Bigjoiner

[Stanislav Lisovskiy]

According to BSpec 49190, when enabling crtcs, we first setup
slave and then master crtc, however for disabling it should go
vice versa, i.e first master, then slave, however current code
does disabling in a same way as enabling. Fix this, by skipping
non-master crtcs, instead of non-slaves.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 0490c6412ab5..68958ba0ef49 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6662,7 +6662,7 @@ static void intel_commit_modeset_disables(struct 
intel_atomic_state *state)
 */
if (!is_trans_port_sync_slave(old_crtc_state) &&
!intel_dp_mst_is_slave_trans(old_crtc_state) &&
-   !intel_crtc_is_bigjoiner_slave(old_crtc_state))
+   !intel_crtc_is_bigjoiner_master(old_crtc_state))
continue;
 
intel_old_crtc_state_disables(state, old_crtc_state,
-- 
2.37.3

[Intel-gfx] Extension detection by enumeration vs attempt to use extension (Was: Re: [PATCH v10 2/2] drm/i915: Allow user to set cache at BO creation)

[Joonas Lahtinen]

Quoting Jordan Justen (2023-05-21 07:30:52)
> On 2023-05-18 22:11:03,  wrote:
> > From: Fei Yang 
> > 
> > To comply with the design that buffer objects shall have immutable
> > cache setting through out their life cycle, {set, get}_caching ioctl's
> > are no longer supported from MTL onward. With that change caching
> > policy can only be set at object creation time. The current code
> > applies a default (platform dependent) cache setting for all objects.
> > However this is not optimal for performance tuning. The patch extends
> > the existing gem_create uAPI to let user set PAT index for the object
> > at creation time.
> > The new extension is platform independent, so UMD's can switch to using
> > this extension for older platforms as well, while {set, get}_caching are
> > still supported on these legacy paltforms for compatibility reason.
> > 
> > Test igt@gem_create@create_ext_set_pat posted at
> > https://patchwork.freedesktop.org/series/117695/
> > 
> > Tested with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878
> > 
> > Signed-off-by: Fei Yang 
> > Cc: Chris Wilson 
> > Cc: Matt Roper 
> > Cc: Andi Shyti 
> > Reviewed-by: Andi Shyti 
> > Acked-by: Jordan Justen 
> 
> Nevertheless, I'm still disappointed my suggestion was so quickly shot
> down.

Sorry to hear that you feel that your suggestion was shot down quickly.
The intent was not to be rude. Attempt was just to make sure we're not
blocking an important patch due to repeat of an orthogonal discussion
which has been discussed to exhaustion in past.

There are pros and cons to both solutions, some of which were recapped
in the thread quickly. We can surely continue the discussion on the
details now that the patch is not blocked.

> I tried to look over our usage Mesa of i915 extensions, and found
> this:
> 
> I915_GEM_CREATE_EXT_MEMORY_REGIONS:
> 
>  * If DRM_I915_QUERY_MEMORY_REGIONS is found
> 
> I915_GEM_CREATE_EXT_PROTECTED_CONTENT:
> 
>  * Probed via the current "robust" method. Resulted in 8s driver
>startup delay in some bad scenarios.

I think this is an another orthogonal topic. Just listing the existence
of that extension in the kernel codebase would not really help.

The fact that an uAPI is known at compile time by kernel doesn't mean it
would not be defunctional / disabled / fused out on the specific system.

>  * Will be guarded by I915_PARAM_PXP_STATUS when available in future
> 
> I915_CONTEXT_CREATE_EXT_SETPARAM (I915_CONTEXT_PARAM_ENGINES):
> 
>  * If DRM_I915_QUERY_ENGINE_INFO is found
> 
> I915_GEM_CREATE_EXT_SET_PAT:
> 
>  * When platform is mtl or newer
> 
> I think we will continue to try to find workarounds that imply the
> extension's existence,

You're not supposed to just probe for existence of an extension in the
kernel codebase, but also check that the extension works on that system.

So probing for the extension array is just half the work. If the KMD
started to block out extensions from the array dynamically, then we
would be doing that based on adding heuristics that are better added in
the userspace. Ultimately you need to have the error handling for the
initialization added anyway to userspace, so there should not be that
much new code that needs adding.

Regards, Joonas

> but it could be nice to have a generic way to
> find out what extensions the kernel knows about.
> 
> -Jordan

[Intel-gfx] [PATCH v2 2/2] drm/i915/dsc: Add rc_range_parameter calculation for YCBCR420

[Suraj Kandpal]

Some rc_range_parameter calculations were missed for YCBCR420,
add them to calculate_rc_param()

--v2
-take into account the new formula to get bpp_i

Cc: Vandita Kulkarni 
Cc: Ankit Nautiyal 
Cc: Uma Shankar 
Signed-off-by: Suraj Kandpal 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 142 --
 1 file changed, 104 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index c64a38363e02..668046f126c6 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -52,23 +52,34 @@ static bool is_pipe_dsc(struct intel_crtc *crtc, enum 
transcoder cpu_transcoder)
return true;
 }
 
+static void
+intel_vdsc_set_min_max_qp(struct drm_dsc_config *vdsc_cfg, int buf,
+ int bpp)
+{
+   int bpc = vdsc_cfg->bits_per_component;
+
+   /* Read range_minqp and range_max_qp from qp tables */
+   vdsc_cfg->rc_range_params[buf].range_min_qp =
+   intel_lookup_range_min_qp(bpc, buf, bpp, vdsc_cfg->native_420);
+   vdsc_cfg->rc_range_params[buf].range_max_qp =
+   intel_lookup_range_max_qp(bpc, buf, bpp, vdsc_cfg->native_420);
+}
+
+/* Calculate RC Params using the below two methods:
+ * 1. DSCParameterValuesVESA V1-2 spreadsheet
+ * 2. VESA DSC 1.2a DSC Tools Application Note
+ * Above two methods use a common formula to derive values for any combination 
of DSC
+ * variables. The formula approach may yield slight differences in the derived 
PPS
+ * parameters from the original parameter sets. These differences are not 
consequential
+ * to the coding performance because all parameter sets have been shown to 
produce
+ * visually lossless quality (provides the same PPS values as
+ * DSCParameterValuesVESA V1-2 spreadsheet)
+ */
 static void
 calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
 {
int bpc = vdsc_cfg->bits_per_component;
int bpp = vdsc_cfg->bits_per_pixel >> 4;
-   static const s8 ofs_und6[] = {
-   0, -2, -2, -4, -6, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
-   };
-   static const s8 ofs_und8[] = {
-   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12, -12, -12
-   };
-   static const s8 ofs_und12[] = {
-   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12, -12, -12
-   };
-   static const s8 ofs_und15[] = {
-   10, 8, 6, 4, 2, 0, -2, -4, -6, -8, -10, -10, -12, -12, -12
-   };
int qp_bpc_modifier = (bpc - 8) * 2;
u32 res, buf_i, bpp_i;
 
@@ -113,33 +124,88 @@ calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
 
-   bpp_i  = (2 * (bpp - 6));
-   for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
-   u8 range_bpg_offset;
-
-   /* Read range_minqp and range_max_qp from qp tables */
-   vdsc_cfg->rc_range_params[buf_i].range_min_qp =
-   intel_lookup_range_min_qp(bpc, buf_i, bpp_i, 
vdsc_cfg->native_420);
-   vdsc_cfg->rc_range_params[buf_i].range_max_qp =
-   intel_lookup_range_max_qp(bpc, buf_i, bpp_i, 
vdsc_cfg->native_420);
-
-   /* Calculate range_bpg_offset */
-   if (bpp <= 6) {
-   range_bpg_offset = ofs_und6[buf_i];
-   } else if (bpp <= 8) {
-   res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] - 
ofs_und6[buf_i])), 2);
-   range_bpg_offset = ofs_und6[buf_i] + res;
-   } else if (bpp <= 12) {
-   range_bpg_offset = ofs_und8[buf_i];
-   } else if (bpp <= 15) {
-   res = DIV_ROUND_UP(((bpp - 12) * (ofs_und15[buf_i] - 
ofs_und12[buf_i])), 3);
-   range_bpg_offset = ofs_und12[buf_i] + res;
-   } else {
-   range_bpg_offset = ofs_und15[buf_i];
+   if (vdsc_cfg->native_420) {
+   static const s8 ofs_und4[] = {
+   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, 
-12, -12
+   };
+   static const s8 ofs_und5[] = {
+   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12, 
-12, -12
+   };
+   static const s8 ofs_und6[] = {
+   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12, 
-12, -12
+   };
+   static const s8 ofs_und8[] = {
+   10, 8, 6, 4, 2, 0, -2, -4, -6, -8, -10, -10, -12, -12, 
-12
+   };
+
+   bpp_i  = bpp - 8;
+   for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
+   u8 range_bpg_offset;
+
+   intel_vdsc_set_min_max_qp(vdsc_cfg, buf_i, bpp_i);
+
+   /* Calculate range_bpg_offs

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/fbdev: Remove DRM's helpers for fbdev I/O (rev4)

[Patchwork]

== Series Details ==

Series: drm/fbdev: Remove DRM's helpers for fbdev I/O (rev4)
URL   : https://patchwork.freedesktop.org/series/117671/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_117671v4_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 8)
--

  Additional (1): shard-rkl0 

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@kms_flip@wf_vblank-ts-check-interruptible@a-hdmi-a4:
- {shard-dg1}:[PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-dg1-14/igt@kms_flip@wf_vblank-ts-check-interrupti...@a-hdmi-a4.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117671v4/shard-dg1-18/igt@kms_flip@wf_vblank-ts-check-interrupti...@a-hdmi-a4.html

  * igt@kms_flip@wf_vblank-ts-check-interruptible@b-hdmi-a4:
- {shard-dg1}:[PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-dg1-14/igt@kms_flip@wf_vblank-ts-check-interrupti...@b-hdmi-a4.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117671v4/shard-dg1-18/igt@kms_flip@wf_vblank-ts-check-interrupti...@b-hdmi-a4.html

  
New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_117671v4_full:

### New IGT tests (278) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-2:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-d-hdmi-a-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

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

[Joonas Lahtinen]

Hi Dave & Daniel,

Here goes drm-intel-fixes for v4.6-rc4.

Again just one fix, for pipejoiner config pipe disabling.

Regards, Joonas

***

drm-intel-fixes-2023-05-25:

PIPEDMC disabling fix for bigjoiner config

The following changes since commit 44c026a73be8038f03dbdeef028b642880cf1511:

  Linux 6.4-rc3 (2023-05-21 14:05:48 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-05-25

for you to fetch changes up to 45dfbd992923f4df174db4e23b96fca7e30d73e2:

  drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration (2023-05-22 
17:10:11 +0300)


PIPEDMC disabling fix for bigjoiner config


Imre Deak (1):
  drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration

 drivers/gpu/drm/i915/display/intel_display.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

Re: [Intel-gfx] [RFC PATCH] drm/ttm: Allow the driver to resolve a WW transaction rollback

[Thomas Hellström]

On Fri, 2023-05-05 at 16:17 +0200, Thomas Hellström wrote:
> Allow drivers to resolve a WW transaction rollback. This allows for
> 1) Putting a lower-priority transaction to sleep allowing another to
> succeed instead both fighting using trylocks.
> 2) Letting the driver know whether a received -ENOMEM is the result
> of
> competition with another WW transaction, which can be resolved using
> rollback and retry or a real -ENOMEM which should be propagated back
> to user-space as a failure.
> 
> Signed-off-by: Thomas Hellström 

Christian, Any objections?

/Thomas


> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 17 +++--
>  include/drm/ttm/ttm_bo.h |  2 ++
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> b/drivers/gpu/drm/ttm/ttm_bo.c
> index bd5dae4d1624..c3ccbea2be3e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -561,6 +561,10 @@ static int ttm_mem_evict_wait_busy(struct
> ttm_buffer_object *busy_bo,
> if (!busy_bo || !ticket)
> return -EBUSY;
>  
> +   /* We want to resolve contention before trying to lock again.
> */
> +   if (ctx->propagate_edeadlk && ctx->contended_bo)
> +   return  -EDEADLK;
> +
> if (ctx->interruptible)
> r = dma_resv_lock_interruptible(busy_bo->base.resv,
>   ticket);
> @@ -575,7 +579,15 @@ static int ttm_mem_evict_wait_busy(struct
> ttm_buffer_object *busy_bo,
> if (!r)
> dma_resv_unlock(busy_bo->base.resv);
>  
> -   return r == -EDEADLK ? -EBUSY : r;
> +   if (r == -EDEADLK) {
> +   if (ctx->propagate_edeadlk) {
> +   ttm_bo_get(busy_bo);
> +   ctx->contended_bo = busy_bo;
> +   }
> +   r = -EBUSY;
> +   }
> +
> +   return r;
>  }
>  
>  int ttm_mem_evict_first(struct ttm_device *bdev,
> @@ -816,7 +828,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object
> *bo,
> goto error;
> }
>  
> -   ret = -ENOMEM;
> +   ret = (ctx->propagate_edeadlk && ctx->contended_bo) ? -
> EDEADLK : -ENOMEM;
> if (!type_found) {
> pr_err(TTM_PFX "No compatible memory type found\n");
> ret = -EINVAL;
> @@ -913,6 +925,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
> if (ret)
> return ret;
> }
> +
> return 0;
>  }
>  EXPORT_SYMBOL(ttm_bo_validate);
> diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
> index 8b113c384236..d8e35a794ce5 100644
> --- a/include/drm/ttm/ttm_bo.h
> +++ b/include/drm/ttm/ttm_bo.h
> @@ -181,8 +181,10 @@ struct ttm_operation_ctx {
> bool gfp_retry_mayfail;
> bool allow_res_evict;
> bool force_alloc;
> +   bool propagate_edeadlk;
> struct dma_resv *resv;
> uint64_t bytes_moved;
> +   struct ttm_buffer_object *contended_bo;
>  };
>  
>  /**

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

[Jani Nikula]

On Thu, 25 May 2023, Joonas Lahtinen  wrote:
> Hi Dave & Daniel,
>
> Here goes drm-intel-fixes for v4.6-rc4.

You're seven years late for that one. ;D

J.

>
> Again just one fix, for pipejoiner config pipe disabling.
>
> Regards, Joonas
>
> ***
>
> drm-intel-fixes-2023-05-25:
>
> PIPEDMC disabling fix for bigjoiner config
>
> The following changes since commit 44c026a73be8038f03dbdeef028b642880cf1511:
>
>   Linux 6.4-rc3 (2023-05-21 14:05:48 -0700)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-05-25
>
> for you to fetch changes up to 45dfbd992923f4df174db4e23b96fca7e30d73e2:
>
>   drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration (2023-05-22 
> 17:10:11 +0300)
>
> 
> PIPEDMC disabling fix for bigjoiner config
>
> 
> Imre Deak (1):
>   drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration
>
>  drivers/gpu/drm/i915/display/intel_display.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v6 09/10] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev

[Liu, Yi L]

> From: Alex Williamson 
> Sent: Thursday, May 25, 2023 3:56 AM
> On Mon, 22 May 2023 04:57:50 -0700
> Yi Liu  wrote:
> 
> > +
> > +/*
> > + * Return devid for vfio_device if the device is owned by the input
> > + * ictx.
> > + * - valid devid > 0 for the device that are bound to the input
> > + *   iommufd_ctx.
> > + * - devid == VFIO_PCI_DEVID_OWNED for the devices that have not
> > + *   been opened but but other device within its group has been
> 
> "but but"

Thanks for catching it.

> 
> > + *   bound to the input iommufd_ctx.
> > + * - devid == VFIO_PCI_DEVID_NOT_OWNED for others. e.g. vdev is
> > + *   NULL.
> > + */
> > +int vfio_iommufd_device_hot_reset_devid(struct vfio_device *vdev,
> > +   struct iommufd_ctx *ictx)
> > +{
> > +   struct iommu_group *group;
> > +   int devid;
> > +
> > +   if (!vdev)
> > +   return VFIO_PCI_DEVID_NOT_OWNED;
> > +
> > +   if (vfio_iommufd_device_ictx(vdev) == ictx)
> > +   return vfio_iommufd_device_id(vdev);
> > +
> > +   group = iommu_group_get(vdev->dev);
> > +   if (!group)
> > +   return VFIO_PCI_DEVID_NOT_OWNED;
> > +
> > +   if (iommufd_ctx_has_group(ictx, group))
> > +   devid = VFIO_PCI_DEVID_OWNED;
> > +   else
> > +   devid = VFIO_PCI_DEVID_NOT_OWNED;
> > +
> > +   iommu_group_put(group);
> > +
> > +   return devid;
> > +}

> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -650,11 +650,53 @@ enum {
> >   * VFIO_DEVICE_GET_PCI_HOT_RESET_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 12,
> >   *   struct vfio_pci_hot_reset_info)
> >   *
> > + * This command is used to query the affected devices in the hot reset for
> > + * a given device.
> > + *
> > + * This command always reports the segment, bus, and devfn information for
> > + * each affected device, and selectively reports the group_id or devid per
> > + * the way how the calling device is opened.
> > + *
> > + * - If the calling device is opened via the traditional group/container
> > + *   API, group_id is reported.  User should check if it has owned all
> > + *   the affected devices and provides a set of group fds to prove the
> > + *   ownership in VFIO_DEVICE_PCI_HOT_RESET ioctl.
> > + *
> > + * - If the calling device is opened as a cdev, devid is reported.
> > + *   Flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID is set to indicate this
> > + *   data type.  For a given affected device, it is considered owned by
> > + *   this interface if it meets the following conditions:
> > + *   1) Has a valid devid within the iommufd_ctx of the calling device.
> > + *  Ownership cannot be determined across separate iommufd_ctx and the
> > + *  cdev calling conventions do not support a proof-of-ownership model
> > + *  as provided in the legacy group interface.  In this case a valid
> > + *  devid with value greater than zero is provided in the return
> > + *  structure.
> > + *   2) Does not have a valid devid within the iommufd_ctx of the calling
> > + *  device, but belongs to the same IOMMU group as the calling device
> > + *  or another opened device that has a valid devid within the
> > + *  iommufd_ctx of the calling device.  This provides implicit 
> > ownership
> > + *  for devices within the same DMA isolation context.  In this case
> > + *  the invalid devid value of zero is provided in the return 
> > structure.
> > + *
> > + *   A devid value of -1 is provided in the return structure for devices
> 
> s/zero/VFIO_PCI_DEVID_OWNED/
> 
> s/-1/VFIO_PCI_DEVID_NOT_OWNED/

Will do.

> 2) above and previously in the code comment where I noted the repeated
> "but" still doesn't actually describe the requirement as I noted in the
> last review.  The user implicitly owns a device if they own another
> device within the IOMMU group, but we also impose a dev_set requirement
> in the hot reset path.  All affected devices need to be represented in
> the dev_set, ex. bound to a vfio driver.

Yes. it is. Btw. dev_set is not visible to user. Is it good to mention it
in uapi header especially w.r.t. the below potential relaxing of this
requirement?

>  It's possible that requirement
> might be relaxed in the new DMA ownership model, but as it is right
> now, the code enforces that requirement and any new discussion about
> what makes hot-reset available should note both the ownership and
> dev_set requirement.  Thanks,

I think your point is that if an iommufd_ctx has acquired DMA ownerhisp
of an iommu_group, it means the device is owned. And it should not
matter whether all the devices in the iommu_group is present in the
dev_set. It is allowed that some devices are bound to pci-stub or
pcieport driver. Is it?

Actually I have a doubt on it. IIUC, the above requirement on dev_set
is to ensure the reset to the devices are protected by the dev_set->lock.
So that either the reset issued by driver itself or a hot reset request
from user, there is no race. But i

Re: [Intel-gfx] [RFC PATCH] drm/ttm: Allow the driver to resolve a WW transaction rollback

[Christian König]

Am 25.05.23 um 14:59 schrieb Thomas Hellström:

On Fri, 2023-05-05 at 16:17 +0200, Thomas Hellström wrote:

Allow drivers to resolve a WW transaction rollback. This allows for
1) Putting a lower-priority transaction to sleep allowing another to
succeed instead both fighting using trylocks.
2) Letting the driver know whether a received -ENOMEM is the result
of
competition with another WW transaction, which can be resolved using
rollback and retry or a real -ENOMEM which should be propagated back
to user-space as a failure.

Signed-off-by: Thomas Hellström 

Christian, Any objections?


General idea sounds like what I had in mind as well, but I've moved both 
my office and household in the last two weeks and are now digging 
through >800 unread mails/patches.


Give me some days to catch up and I can take a detailed look.

Christian.



/Thomas



---
  drivers/gpu/drm/ttm/ttm_bo.c | 17 +++--
  include/drm/ttm/ttm_bo.h |  2 ++
  2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index bd5dae4d1624..c3ccbea2be3e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -561,6 +561,10 @@ static int ttm_mem_evict_wait_busy(struct
ttm_buffer_object *busy_bo,
 if (!busy_bo || !ticket)
 return -EBUSY;
  
+   /* We want to resolve contention before trying to lock again.

*/
+   if (ctx->propagate_edeadlk && ctx->contended_bo)
+   return  -EDEADLK;
+
 if (ctx->interruptible)
 r = dma_resv_lock_interruptible(busy_bo->base.resv,
   ticket);
@@ -575,7 +579,15 @@ static int ttm_mem_evict_wait_busy(struct
ttm_buffer_object *busy_bo,
 if (!r)
 dma_resv_unlock(busy_bo->base.resv);
  
-   return r == -EDEADLK ? -EBUSY : r;

+   if (r == -EDEADLK) {
+   if (ctx->propagate_edeadlk) {
+   ttm_bo_get(busy_bo);
+   ctx->contended_bo = busy_bo;
+   }
+   r = -EBUSY;
+   }
+
+   return r;
  }
  
  int ttm_mem_evict_first(struct ttm_device *bdev,

@@ -816,7 +828,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object
*bo,
 goto error;
 }
  
-   ret = -ENOMEM;

+   ret = (ctx->propagate_edeadlk && ctx->contended_bo) ? -
EDEADLK : -ENOMEM;
 if (!type_found) {
 pr_err(TTM_PFX "No compatible memory type found\n");
 ret = -EINVAL;
@@ -913,6 +925,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
 if (ret)
 return ret;
 }
+
 return 0;
  }
  EXPORT_SYMBOL(ttm_bo_validate);
diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
index 8b113c384236..d8e35a794ce5 100644
--- a/include/drm/ttm/ttm_bo.h
+++ b/include/drm/ttm/ttm_bo.h
@@ -181,8 +181,10 @@ struct ttm_operation_ctx {
 bool gfp_retry_mayfail;
 bool allow_res_evict;
 bool force_alloc;
+   bool propagate_edeadlk;
 struct dma_resv *resv;
 uint64_t bytes_moved;
+   struct ttm_buffer_object *contended_bo;
  };
  
  /**

Re: [Intel-gfx] [PATCH v8 7/7] drm/i915/mtl: Add support for PM DEMAND

[Gustavo Sousa]

Hi, Vinod.

Thanks for the new version. I decided to take one final look at the
overall patch I have found some issues yet. Sorry I didn't catch them
before!

Please, see my comments inline.

Quoting Vinod Govindapillai (2023-05-24 20:03:42-03:00)
>From: Mika Kahola 
>
>MTL introduces a new way to instruct the PUnit with
>power and bandwidth requirements of DE. Add the functionality
>to program the registers and handle waits using interrupts.
>The current wait time for timeouts is programmed for 10 msecs to
>factor in the worst case scenarios. Changes made to use REG_BIT
>for a register that we touched(GEN8_DE_MISC_IER _MMIO).
>
>Wa_14016740474 is added which applies to Xe_LPD+ display
>
>v2: checkpatch warning fixes, simplify program pmdemand part
>
>v3: update to dbufs and pipes values to pmdemand register(stan)
>Removed the macro usage in update_pmdemand_values()
>
>v4: move the pmdemand_pre_plane_update before cdclk update
>pmdemand_needs_update included cdclk params comparisons
>pmdemand_state NULL check (Gustavo)
>pmdemand.o in sorted order in the makefile (Jani)
>update pmdemand misc irq handler loop (Gustavo)
>active phys bitmask and programming correction (Gustavo)
>
>v5: simplify pmdemand_state structure
>simplify methods to find active phys and max port clock
>Timeout in case of previou pmdemand task pending (Gustavo)
>
>v6: rebasing
>updates to max_ddiclk calculations (Gustavo)
>updates to active_phys count method (Gustavo)
>
>v7: use two separate loop to iterate throug old and new
>crtc states to calculate the active phys (Gustavo)
>
>Bspec: 66451, 64636, 64602, 64603
>Cc: Matt Atwood 
>Cc: Matt Roper 
>Cc: Lucas De Marchi 
>Cc: Gustavo Sousa 
>Signed-off-by: José Roberto de Souza 
>Signed-off-by: Radhakrishna Sripada 
>Signed-off-by: Gustavo Sousa 
>Signed-off-by: Mika Kahola 
>Signed-off-by: Vinod Govindapillai 
>Reviewed-by: Stanislav Lisovskiy 
>---
> drivers/gpu/drm/i915/Makefile |   1 +
> drivers/gpu/drm/i915/display/intel_display.c  |  14 +
> .../gpu/drm/i915/display/intel_display_core.h |   9 +
> .../drm/i915/display/intel_display_driver.c   |   7 +
> .../gpu/drm/i915/display/intel_display_irq.c  |  23 +-
> .../drm/i915/display/intel_display_power.c|   8 +
> drivers/gpu/drm/i915/display/intel_pmdemand.c | 560 ++
> drivers/gpu/drm/i915/display/intel_pmdemand.h |  24 +
> drivers/gpu/drm/i915/i915_reg.h   |  36 +-
> 9 files changed, 678 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h
>
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index dd9ca69f4998..358463d02a57 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -273,6 +273,7 @@ i915-y += \
> display/intel_pch_display.o \
> display/intel_pch_refclk.o \
> display/intel_plane_initial.o \
>+display/intel_pmdemand.o \
> display/intel_psr.o \
> display/intel_quirks.o \
> display/intel_sprite.o \
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>b/drivers/gpu/drm/i915/display/intel_display.c
>index 0490c6412ab5..b3bb2c607650 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -99,6 +99,7 @@
> #include "intel_pcode.h"
> #include "intel_pipe_crc.h"
> #include "intel_plane_initial.h"
>+#include "intel_pmdemand.h"
> #include "intel_pps.h"
> #include "intel_psr.h"
> #include "intel_sdvo.h"
>@@ -6343,6 +6344,10 @@ int intel_atomic_check(struct drm_device *dev,
> return ret;
> }
> 
>+ret = intel_pmdemand_atomic_check(state);
>+if (ret)
>+goto fail;
>+
> ret = intel_atomic_check_crtcs(state);
> if (ret)
> goto fail;
>@@ -6988,6 +6993,14 @@ static void intel_atomic_commit_tail(struct 
>intel_atomic_state *state)
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> crtc->config = new_crtc_state;
> 
>+/*
>+ * In XE_LPD+ Pmdemand combines many parameters such as voltage index,
>+ * plls, cdclk frequency, QGV point selection parameter etc. Voltage
>+ * index, cdclk/ddiclk frequencies are supposed to be configured 
>before
>+ * the cdclk config is set.
>+ */
>+intel_pmdemand_pre_plane_update(state);
>+
> if (state->modeset) {
> drm_atomic_helper_update_legacy_modeset_state(dev, 
> &state->base);
> 
>@@ -7107,6 +7120,7 @@ static void intel_atomic_commit_tail(struct 
>intel_atomic_state *state)
> intel_verify_planes(state);
> 
> intel_sagv_post_plane_update(state);
>+intel_pmdemand_post_plane_update(state);
> 
> drm_atomic_helper_commit_hw_done(&state->base);
> 
>diff --git a/drivers/gpu/drm/i915/display/intel_di

Re: [Intel-gfx] [PATCH v8 7/7] drm/i915/mtl: Add support for PM DEMAND

[Govindapillai, Vinod]

Hi




From: Sousa, Gustavo 
Sent: Thursday, 25 May 2023, 17:06
To: Govindapillai, Vinod ; 
intel-gfx@lists.freedesktop.org 
Cc: Syrjala, Ville ; Lisovskiy, Stanislav 
; Kahola, Mika ; 
Saarinen, Jani 
Subject: Re: [PATCH v8 7/7] drm/i915/mtl: Add support for PM DEMAND

Hi, Vinod.

Thanks for the new version. I decided to take one final look at the
overall patch I have found some issues yet. Sorry I didn't catch them
before!

Please, see my comments inline.

Quoting Vinod Govindapillai (2023-05-24 20:03:42-03:00)
>From: Mika Kahola 
>
>MTL introduces a new way to instruct the PUnit with
>power and bandwidth requirements of DE. Add the functionality
>to program the registers and handle waits using interrupts.
>The current wait time for timeouts is programmed for 10 msecs to
>factor in the worst case scenarios. Changes made to use REG_BIT
>for a register that we touched(GEN8_DE_MISC_IER _MMIO).
>
>Wa_14016740474 is added which applies to Xe_LPD+ display
>
>v2: checkpatch warning fixes, simplify program pmdemand part
>
>v3: update to dbufs and pipes values to pmdemand register(stan)
>Removed the macro usage in update_pmdemand_values()
>
>v4: move the pmdemand_pre_plane_update before cdclk update
>pmdemand_needs_update included cdclk params comparisons
>pmdemand_state NULL check (Gustavo)
>pmdemand.o in sorted order in the makefile (Jani)
>update pmdemand misc irq handler loop (Gustavo)
>active phys bitmask and programming correction (Gustavo)
>
>v5: simplify pmdemand_state structure
>simplify methods to find active phys and max port clock
>Timeout in case of previou pmdemand task pending (Gustavo)
>
>v6: rebasing
>updates to max_ddiclk calculations (Gustavo)
>updates to active_phys count method (Gustavo)
>
>v7: use two separate loop to iterate throug old and new
>crtc states to calculate the active phys (Gustavo)
>
>Bspec: 66451, 64636, 64602, 64603
>Cc: Matt Atwood 
>Cc: Matt Roper 
>Cc: Lucas De Marchi 
>Cc: Gustavo Sousa 
>Signed-off-by: José Roberto de Souza 
>Signed-off-by: Radhakrishna Sripada 
>Signed-off-by: Gustavo Sousa 
>Signed-off-by: Mika Kahola 
>Signed-off-by: Vinod Govindapillai 
>Reviewed-by: Stanislav Lisovskiy 
>---
> drivers/gpu/drm/i915/Makefile |   1 +
> drivers/gpu/drm/i915/display/intel_display.c  |  14 +
> .../gpu/drm/i915/display/intel_display_core.h |   9 +
> .../drm/i915/display/intel_display_driver.c   |   7 +
> .../gpu/drm/i915/display/intel_display_irq.c  |  23 +-
> .../drm/i915/display/intel_display_power.c|   8 +
> drivers/gpu/drm/i915/display/intel_pmdemand.c | 560 ++
> drivers/gpu/drm/i915/display/intel_pmdemand.h |  24 +
> drivers/gpu/drm/i915/i915_reg.h   |  36 +-
> 9 files changed, 678 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h
>
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index dd9ca69f4998..358463d02a57 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -273,6 +273,7 @@ i915-y += \
> display/intel_pch_display.o \
> display/intel_pch_refclk.o \
> display/intel_plane_initial.o \
>+display/intel_pmdemand.o \
> display/intel_psr.o \
> display/intel_quirks.o \
> display/intel_sprite.o \
>diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>b/drivers/gpu/drm/i915/display/intel_display.c
>index 0490c6412ab5..b3bb2c607650 100644
>--- a/drivers/gpu/drm/i915/display/intel_display.c
>+++ b/drivers/gpu/drm/i915/display/intel_display.c
>@@ -99,6 +99,7 @@
> #include "intel_pcode.h"
> #include "intel_pipe_crc.h"
> #include "intel_plane_initial.h"
>+#include "intel_pmdemand.h"
> #include "intel_pps.h"
> #include "intel_psr.h"
> #include "intel_sdvo.h"
>@@ -6343,6 +6344,10 @@ int intel_atomic_check(struct drm_device *dev,
> return ret;
> }
>
>+ret = intel_pmdemand_atomic_check(state);
>+if (ret)
>+goto fail;
>+
> ret = intel_atomic_check_crtcs(state);
> if (ret)
> goto fail;
>@@ -6988,6 +6993,14 @@ static void intel_atomic_commit_tail(struct 
>intel_atomic_state *state)
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> crtc->config = new_crtc_state;
>
>+/*
>+ * In XE_LPD+ Pmdemand combines many parameters such as voltage index,
>+ * plls, cdclk frequency, QGV point selection parameter etc. Voltage
>+ * index, cdclk/ddiclk frequencies are supposed to be configured 
>before
>+ * the cdclk config is set.
>+ */
>+intel_pmdemand_pre_plane_update(state);
>+
> if (state->modeset) {
> drm_atomic_helper_update_legacy_modeset_state(dev, 
> &state->base);
>
>@@ -7107,6 +7120,7 @@ static void intel_atomic_commit_tai

Re: [Intel-gfx] [PATCH v8 7/7] drm/i915/mtl: Add support for PM DEMAND

[Gustavo Sousa]

Quoting Govindapillai, Vinod (2023-05-25 11:31:05-03:00)
>   Hi
>
> (...)
>
>   Can only the phys change without impacting other parameters here?

Not sure to be honest, but, if so, I think we would covering cases like
that with the proposed change. IMO, if we depend on PHYs being
active/non-active, we should track that to in pmdemand_needs_update() be
safe.

One scenario I could think of is an update to switch connectors while
keeping current pipe configuration.

--
Gustavo Sousa

[Intel-gfx] ✓ Fi.CI.IGT: success for DSC misc fixes (rev2)

[Patchwork]

== Series Details ==

Series: DSC misc fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/117662/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_117662v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_117662v2_full:

### New IGT tests (289) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-1:
- Statuses : 3 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-1:
- Statuses : 3 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-d-hdmi-a-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-c-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-d-hdmi-a-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-hdmi-a-1:
- Statuses : 3 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-b-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_pl

Re: [Intel-gfx] [PATCH v8 7/7] drm/i915/mtl: Add support for PM DEMAND

[Govindapillai, Vinod]

Hi

I think so far with my trials port clock changes in sync with phys. As pmdemand 
atomic check is called many times, I don't think optimizing is bad.

Br
Vinod


From: Sousa, Gustavo 
Sent: Thursday, 25 May 2023, 17:58
To: Govindapillai, Vinod ; 
intel-gfx@lists.freedesktop.org 
Cc: Syrjala, Ville ; Lisovskiy, Stanislav 
; Kahola, Mika ; 
Saarinen, Jani 
Subject: Re: [PATCH v8 7/7] drm/i915/mtl: Add support for PM DEMAND

Quoting Govindapillai, Vinod (2023-05-25 11:31:05-03:00)
>   Hi
>
> (...)
>
>   Can only the phys change without impacting other parameters here?

Not sure to be honest, but, if so, I think we would covering cases like
that with the proposed change. IMO, if we depend on PHYs being
active/non-active, we should track that to in pmdemand_needs_update() be
safe.

One scenario I could think of is an update to switch connectors while
keeping current pipe configuration.

--
Gustavo Sousa

Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation

[Yang, Fei]

Sounds weird to have a platform restriction on uAPI though. UMD not using this 
extension is not a problem, is it?



From: Tvrtko Ursulin 
Sent: Thursday, May 25, 2023 1:33 AM
To: Yang, Fei ; intel-gfx@lists.freedesktop.org 

Cc: dri-de...@lists.freedesktop.org ; Vivi, 
Rodrigo 
Subject: Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at 
BO creation


On 24/05/2023 21:02, fei.y...@intel.com wrote:
> From: Fei Yang 
>
> This series introduce a new extension for GEM_CREATE,
> 1. end support for set caching ioctl [PATCH 1/2]
> 2. add set_pat extension for gem_create [PATCH 2/2]
>
> v2: drop one patch that was merged separately
>  commit 341ad0e8e254 ("drm/i915/mtl: Add PTE encode function")
> v3: rebased on https://patchwork.freedesktop.org/series/117082/
> v4: fix missing unlock introduced in v3, and
>  solve a rebase conflict
> v5: replace obj->cache_level with pat_set_by_user,
>  fix i915_cache_level_str() for legacy platforms.
> v6: rebased on https://patchwork.freedesktop.org/series/117480/
> v7: rebased on https://patchwork.freedesktop.org/series/117528/
> v8: dropped the two dependent patches that has been merged
>  separately. Add IGT link and Tested-by (MESA).
> v9: addressing comments (Andi)
> v10: acked-by and tested-by MESA
> v11: drop "end support for set caching ioctl" (merged)
>   remove tools/include/uapi/drm/i915_drm.h
> v12: drop Bspec reference in comment. add to commit message instead
>
> Fei Yang (1):
>drm/i915: Allow user to set cache at BO creation
>
>   drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
>   drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
>   include/uapi/drm/i915_drm.h| 41 ++
>   3 files changed, 83 insertions(+)
>

Do you also have a Test-with: run against the new IGT somewhere?

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation

[Yang, Fei]

> On 24/05/2023 21:02, fei.y...@intel.com wrote:
>> From: Fei Yang 
>>
>> This series introduce a new extension for GEM_CREATE,
>> 1. end support for set caching ioctl [PATCH 1/2]
>> 2. add set_pat extension for gem_create [PATCH 2/2]
>>
>> v2: drop one patch that was merged separately
>>  commit 341ad0e8e254 ("drm/i915/mtl: Add PTE encode function")
>> v3: rebased on https://patchwork.freedesktop.org/series/117082/
>> v4: fix missing unlock introduced in v3, and
>>  solve a rebase conflict
>> v5: replace obj->cache_level with pat_set_by_user,
>>  fix i915_cache_level_str() for legacy platforms.
>> v6: rebased on https://patchwork.freedesktop.org/series/117480/
>> v7: rebased on https://patchwork.freedesktop.org/series/117528/
>> v8: dropped the two dependent patches that has been merged
>>  separately. Add IGT link and Tested-by (MESA).
>> v9: addressing comments (Andi)
>> v10: acked-by and tested-by MESA
>> v11: drop "end support for set caching ioctl" (merged)
>>   remove tools/include/uapi/drm/i915_drm.h
>> v12: drop Bspec reference in comment. add to commit message instead
>>
>> Fei Yang (1):
>>drm/i915: Allow user to set cache at BO creation
>>
>>   drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
>>   drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
>>   include/uapi/drm/i915_drm.h| 41 ++
>>   3 files changed, 83 insertions(+)
>>
>
> Do you also have a Test-with: run against the new IGT somewhere?

I ran locate test, not sure how to get a IGT result with updated kernel on 
patchwork,
looks like a chicken and egg problem.

> Regards,
>
> Tvrtko

Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at BO creation

[Yang, Fei]

Sorry replied on top of wrong thread.

From: Yang, Fei 
Sent: Thursday, May 25, 2023 8:12 AM
To: Tvrtko Ursulin ; 
intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Vivi, Rodrigo 
Subject: Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at 
BO creation


Sounds weird to have a platform restriction on uAPI though. UMD not using this 
extension is not a problem, is it?


From: Tvrtko Ursulin 
mailto:tvrtko.ursu...@linux.intel.com>>
Sent: Thursday, May 25, 2023 1:33 AM
To: Yang, Fei mailto:fei.y...@intel.com>>; 
intel-gfx@lists.freedesktop.org 
mailto:intel-gfx@lists.freedesktop.org>>
Cc: dri-de...@lists.freedesktop.org 
mailto:dri-de...@lists.freedesktop.org>>; 
Vivi, Rodrigo mailto:rodrigo.v...@intel.com>>
Subject: Re: [Intel-gfx] [PATCH v12 0/1] drm/i915: Allow user to set cache at 
BO creation


On 24/05/2023 21:02, fei.y...@intel.com wrote:
> From: Fei Yang mailto:fei.y...@intel.com>>
>
> This series introduce a new extension for GEM_CREATE,
> 1. end support for set caching ioctl [PATCH 1/2]
> 2. add set_pat extension for gem_create [PATCH 2/2]
>
> v2: drop one patch that was merged separately
>  commit 341ad0e8e254 ("drm/i915/mtl: Add PTE encode function")
> v3: rebased on https://patchwork.freedesktop.org/series/117082/
> v4: fix missing unlock introduced in v3, and
>  solve a rebase conflict
> v5: replace obj->cache_level with pat_set_by_user,
>  fix i915_cache_level_str() for legacy platforms.
> v6: rebased on https://patchwork.freedesktop.org/series/117480/
> v7: rebased on https://patchwork.freedesktop.org/series/117528/
> v8: dropped the two dependent patches that has been merged
>  separately. Add IGT link and Tested-by (MESA).
> v9: addressing comments (Andi)
> v10: acked-by and tested-by MESA
> v11: drop "end support for set caching ioctl" (merged)
>   remove tools/include/uapi/drm/i915_drm.h
> v12: drop Bspec reference in comment. add to commit message instead
>
> Fei Yang (1):
>drm/i915: Allow user to set cache at BO creation
>
>   drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
>   drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
>   include/uapi/drm/i915_drm.h| 41 ++
>   3 files changed, 83 insertions(+)
>

Do you also have a Test-with: run against the new IGT somewhere?

Regards,

Tvrtko

Re: [Intel-gfx] [PATCH v11 20/23] vfio: Add VFIO_DEVICE_[AT|DE]TACH_IOMMUFD_PT

[Alex Williamson]

On Thu, 25 May 2023 03:03:54 +
"Liu, Yi L"  wrote:

> > From: Alex Williamson 
> > Sent: Wednesday, May 24, 2023 11:32 PM
> > 
> > On Wed, 24 May 2023 02:12:14 +
> > "Liu, Yi L"  wrote:
> >   
> > > > From: Alex Williamson 
> > > > Sent: Tuesday, May 23, 2023 11:50 PM
> > > >
> > > > On Tue, 23 May 2023 01:20:17 +
> > > > "Liu, Yi L"  wrote:
> > > >  
> > > > > > From: Alex Williamson 
> > > > > > Sent: Tuesday, May 23, 2023 6:16 AM
> > > > > >
> > > > > > On Sat, 13 May 2023 06:28:24 -0700
> > > > > > Yi Liu  wrote:
> > > > > >  
> > > > > > >   return kasprintf(GFP_KERNEL, "vfio/devices/%s", dev_name(dev));
> > > > > > > diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> > > > > > > index 83575b65ea01..799ea322a7d4 100644
> > > > > > > --- a/drivers/vfio/iommufd.c
> > > > > > > +++ b/drivers/vfio/iommufd.c
> > > > > > > @@ -112,6 +112,24 @@ void vfio_iommufd_unbind(struct 
> > > > > > > vfio_device_file *df)
> > > > > > >   vdev->ops->unbind_iommufd(vdev);
> > > > > > >  }
> > > > > > >
> > > > > > > +int vfio_iommufd_attach(struct vfio_device *vdev, u32 *pt_id)
> > > > > > > +{
> > > > > > > + lockdep_assert_held(&vdev->dev_set->lock);
> > > > > > > +
> > > > > > > + if (vfio_device_is_noiommu(vdev))
> > > > > > > + return 0;  
> > > > > >
> > > > > > Isn't this an invalid operation for a noiommu cdev, ie. -EINVAL?  We
> > > > > > return success and copy back the provided pt_id, why would a user 
> > > > > > not
> > > > > > consider it a bug that they can't use whatever value was there with
> > > > > > iommufd?  
> > > > >
> > > > > Yes, this is the question I asked in [1]. At that time, it appears to 
> > > > > me
> > > > > that better to allow it [2]. Maybe it's more suitable to ask it here. 
> > > > >  
> > > >
> > > > From an API perspective it seems wrong.  We return success without
> > > > doing anything.  A user would be right to consider it a bug that the
> > > > attach operation works but there's not actually any association to the
> > > > IOAS.  Thanks,  
> > >
> > > The current version is kind of tradeoff based on prior remarks when
> > > I asked the question. As prior comment[2], it appears to me the attach
> > > shall success for noiommu devices as well, but per your remark it seems
> > > not in plan. So anyway, we may just fail the attach/detach for noiommu
> > > devices. Is it?  
> > 
> > If a user creates an ioas within an iommufd, attaches a device to that
> > ioas and populates it with mappings, wouldn't the user expect the
> > device to have access to and honor those mappings?  I think that's the
> > path we're headed down if we report a successful attach of a noiommu
> > device to an ioas.  
> 
> makes sense. Let's just fail attach/detach for noiommu devices.
> 
> > 
> > We need to keep in mind that noiommu was meant to be a minimally
> > intrusive mechanism to provide a dummy vfio IOMMU backend and satisfy
> > the group requirements, solely for the purpose of making use of the
> > vfio device interface and without providing any DMA mapping services or
> > expectations.  IMO, an argument that we need the attach op to succeed in
> > order to avoid too much disruption in userspace code is nonsense.  On
> > the contrary, userspace needs to be very aware of this difference and
> > we shouldn't invest effort trying to make noiommu more convenient to
> > use.  It's inherently unsafe.
> > 
> > I'm not fond of what a mess noiommu has become with cdev, we're well
> > beyond the minimal code trickery of the legacy implementation.  I hate
> > to ask, but could we reiterate our requirements for noiommu as a part of
> > the native iommufd interface for vfio?  The nested userspace requirement
> > is gone now that hypervisors have vIOMMU support, so my assumption is
> > that this is only for bare metal systems without an IOMMU, which
> > ideally are less and less prevalent.  Are there any noiommu userspaces
> > that are actually going to adopt the noiommu cdev interface?  What
> > terrible things happen if noiommu only exists in the vfio group compat
> > interface to iommufd and at some distant point in the future dies when
> > that gets disabled?  
> 
> vIOMMU may introduce some performance deduction if there
> are frequent map/unmap.

We use passthrough mode of the vIOMMU to negate that overhead for guest
drivers and vfio drivers have typically learned by now that dynamic
mappings using the vfio type1 mapping API are a bad idea.

> As far as I know, some cloud service
> providers are more willing to use noiommu mode within VM.

Sure, the VM itself is still isolated by the host IOMMU, but it's
clearly an extra maintenance and development burden when we should
instead be encouraging those use cases to use vIOMMU rather than
porting to a different noiommu uAPI.  Even if the host is not exposed,
any sort of security and support best practices in the guest should
favor a vIOMMU solution.

> Besides the performance consideration, using a booting a VM
> without vI

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Reset only one lane in case of MFD

[Patchwork]

== Series Details ==

Series: drm/i915/mtl: Reset only one lane in case of MFD
URL   : https://patchwork.freedesktop.org/series/118308/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_118308v1_full


Summary
---

  **FAILURE**

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

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_invalid_mode@bad-htotal:
- shard-snb:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118308v1/shard-snb1/igt@kms_invalid_m...@bad-htotal.html

  
New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_118308v1_full:

### New IGT tests (280) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-1:
- Statuses : 3 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-1:
- Statuses : 3 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-d-hdmi-a-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-c-hdmi-a-1:
-

[Intel-gfx] [CI v12 0/1] drm/i915: Allow user to set cache at BO creation

[Andi Shyti]

From: Fei Yang 

[ Just resending this patch to in order to have the results from the igt's
written for this patch ]

This series introduce a new extension for GEM_CREATE,
1. end support for set caching ioctl [PATCH 1/2]
2. add set_pat extension for gem_create [PATCH 2/2]

v2: drop one patch that was merged separately
commit 341ad0e8e254 ("drm/i915/mtl: Add PTE encode function")
v3: rebased on https://patchwork.freedesktop.org/series/117082/
v4: fix missing unlock introduced in v3, and
solve a rebase conflict
v5: replace obj->cache_level with pat_set_by_user,
fix i915_cache_level_str() for legacy platforms.
v6: rebased on https://patchwork.freedesktop.org/series/117480/
v7: rebased on https://patchwork.freedesktop.org/series/117528/
v8: dropped the two dependent patches that has been merged
separately. Add IGT link and Tested-by (MESA).
v9: addressing comments (Andi)
v10: acked-by and tested-by MESA
v11: drop "end support for set caching ioctl" (merged)
 remove tools/include/uapi/drm/i915_drm.h
v12: drop Bspec reference in comment. add to commit message instead

Test-with: 20230524155610.360748-2-fei.y...@intel.com

Fei Yang (1):
  drm/i915: Allow user to set cache at BO creation

 drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
 include/uapi/drm/i915_drm.h| 41 ++
 3 files changed, 83 insertions(+)

-- 
2.40.1

[Intel-gfx] [CI v12 1/1] drm/i915: Allow user to set cache at BO creation

[Andi Shyti]

From: Fei Yang 

To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a default (platform dependent) cache setting for all objects.
However this is not optimal for performance tuning. The patch extends
the existing gem_create uAPI to let user set PAT index for the object
at creation time.
The new extension is platform independent, so UMD's can switch to using
this extension for older platforms as well, while {set, get}_caching are
still supported on these legacy paltforms for compatibility reason.

BSpec: 45101

Test igt@gem_create@create_ext_set_pat posted at
https://patchwork.freedesktop.org/series/118314/

Tested with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878

Signed-off-by: Fei Yang 
Cc: Chris Wilson 
Cc: Matt Roper 
Cc: Andi Shyti 
Reviewed-by: Andi Shyti 
Acked-by: Jordan Justen 
Tested-by: Jordan Justen 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
 include/uapi/drm/i915_drm.h| 41 ++
 3 files changed, 83 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index bfe1dbda4cb75..644a936248ad5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -245,6 +245,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+   unsigned int pat_index;
 };
 
 static void repr_placements(char *buf, size_t size,
@@ -394,11 +395,39 @@ static int ext_set_protected(struct i915_user_extension 
__user *base, void *data
return 0;
 }
 
+static int ext_set_pat(struct i915_user_extension __user *base, void *data)
+{
+   struct create_ext *ext_data = data;
+   struct drm_i915_private *i915 = ext_data->i915;
+   struct drm_i915_gem_create_ext_set_pat ext;
+   unsigned int max_pat_index;
+
+   BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
+offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
+
+   if (copy_from_user(&ext, base, sizeof(ext)))
+   return -EFAULT;
+
+   max_pat_index = INTEL_INFO(i915)->max_pat_index;
+
+   if (ext.pat_index > max_pat_index) {
+   drm_dbg(&i915->drm, "PAT index is invalid: %u\n",
+   ext.pat_index);
+   return -EINVAL;
+   }
+
+   ext_data->pat_index = ext.pat_index;
+
+   return 0;
+}
+
 static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+   [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
 };
 
+#define PAT_INDEX_NOT_SET  0x
 /**
  * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle to 
it.
  * @dev: drm device pointer
@@ -418,6 +447,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
 
+   ext_data.pat_index = PAT_INDEX_NOT_SET;
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
   create_extensions,
   ARRAY_SIZE(create_extensions),
@@ -454,5 +484,11 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (IS_ERR(obj))
return PTR_ERR(obj);
 
+   if (ext_data.pat_index != PAT_INDEX_NOT_SET) {
+   i915_gem_object_set_pat_index(obj, ext_data.pat_index);
+   /* Mark pat_index is set by UMD */
+   obj->pat_set_by_user = true;
+   }
+
return i915_gem_publish(obj, file, &args->size, &args->handle);
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 46a19b099ec88..97ac6fb37958f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -208,6 +208,12 @@ bool i915_gem_object_can_bypass_llc(struct 
drm_i915_gem_object *obj)
if (!(obj->flags & I915_BO_ALLOC_USER))
return false;
 
+   /*
+* Always flush cache for UMD objects at creation time.
+*/
+   if (obj->pat_set_by_user)
+   return true;
+
/*
 * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
 * possible for userspace to bypass the GTT caching bits set by the
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f31dfacde6014..4083a23e0614f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3679,9 +3679,13 @@ struct drm_i915_gem_create_ex

Re: [Intel-gfx] [PATCH] drm/i915/gsc: use system include style for drm headers

[Ceraolo Spurio, Daniele]

On 5/25/2023 2:49 AM, Jani Nikula wrote:

Use <> instead of "" for including headers from include/.

Fixes: 8a9bf29546a1 ("drm/i915/gsc: add initial support for GSC proxy")
Cc: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Signed-off-by: Jani Nikula 


dumb mistake, thanks for fixing it

Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
  drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
index ebee0b5a2c1d..5f138de3c14f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c
@@ -5,8 +5,8 @@
  
  #include 
  
-#include "drm/i915_component.h"

-#include "drm/i915_gsc_proxy_mei_interface.h"
+#include 
+#include 
  
  #include "gt/intel_gt.h"

  #include "gt/intel_gt_print.h"

[Intel-gfx] [linux-next:master] BUILD REGRESSION 6a3d37b4d885129561e1cef361216f00472f7d2e

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 6a3d37b4d885129561e1cef361216f00472f7d2e  Add linux-next specific 
files for 20230525

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202305241902.uvhtmoxa-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202305251508.qswas1hl-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202305251510.u0r2as7k-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

ERROR: modpost: "amdgpu_show_fdinfo" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
undefined!
drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated 
fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
drivers/gpu/drm/i915/display/intel_display.c:6012:3: warning: unannotated 
fall-through between switch labels [-Wimplicit-fallthrough]
hppa-linux-ld: drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:(.rodata+0x2a8): 
undefined reference to `amdgpu_show_fdinfo'

Unverified Error/Warning (likely false positive, please contact us if 
interested):

fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of 
'cifs_sb'
fs/smb/client/cifssmb.c:4089 CIFSFindFirst() warn: missing error code? 'rc'
fs/smb/client/cifssmb.c:4216 CIFSFindNext() warn: missing error code? 'rc'
fs/smb/client/connect.c:2725 cifs_match_super() error: 'tlink' dereferencing 
possible ERR_PTR()
fs/smb/client/connect.c:2924 generic_ip_connect() error: we previously assumed 
'socket' could be null (see line 2912)
fs/smb/client/smb2pdu.c:3729 SMB2_change_notify() error: we previously assumed 
'plen' could be null (see line 3688)
fs/xfs/scrub/fscounters.c:459 xchk_fscounters() warn: ignoring unreachable code.
kernel/watchdog.c:40:19: sparse: sparse: symbol 
'watchdog_hardlockup_user_enabled' was not declared. Should it be static?
kernel/watchdog.c:41:19: sparse: sparse: symbol 
'watchdog_softlockup_user_enabled' was not declared. Should it be static?

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- arm-randconfig-r025-20230524
|   `-- ERROR:amdgpu_show_fdinfo-drivers-gpu-drm-amd-amdgpu-amdgpu.ko-undefined
|-- i386-randconfig-m021-20230524
|   `-- 
fs-xfs-scrub-fscounters.c-xchk_fscounters()-warn:ignoring-unreachable-code.
|-- i386-randconfig-s032-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- ia64-buildonly-randconfig-r005-20230524
|   `-- ERROR:amdgpu_show_fdinfo-drivers-gpu-drm-amd-amdgpu-amdgpu.ko-undefined
|-- ia64-randconfig-s031-20230524
|   |-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_hardlockup_user_enabled-was-not-declared.-Should-it-be-static
|   `-- 
kernel-watchdog.c:sparse:sparse:symbol-watchdog_softlockup_user_enabled-was-not-declared.-Should-it-be-static
|-- parisc-randconfig-r031-20230524
|   `-- 
hppa-linux-ld:drivers-gpu-drm-amd-amdgpu-amdgpu_drv.o:(.rodata):undefined-reference-to-amdgpu_show_fdinfo
`-- x86_64-randconfig-m001-20230524
|-- 
fs-smb-client-cifsfs.c-cifs_smb3_do_mount()-warn:possible-memory-leak-of-cifs_sb
|-- fs-smb-client-cifssmb.c-CIFSFindFirst()-warn:missing-error-code-rc
|-- fs-smb-client-cifssmb.c-CIFSFindNext()-warn:missing-error-code-rc
|-- 
fs-smb-client-connect.c-cifs_match_super()-error:tlink-dereferencing-possible-ERR_PTR()
|-- 
fs-smb-client-connect.c-generic_ip_connect()-error:we-previously-assumed-socket-could-be-null-(see-line-)
`-- 
fs-smb-client-smb2pdu.c-SMB2_change_notify()-error:we-previously-assumed-plen-could-be-null-(see-line-)
clang_recent_errors
|-- i386-randconfig-i011-20230524
|   `-- 
drivers-gpu-drm-i915-display-intel_display.c:warning:unannotated-fall-through-between-switch-labels
|-- i386-randconfig-i014-20230524
|   `-- 
drivers-gpu-drm-i915-display-intel_display.c:warning:unannotated-fall-through-between-switch-labels
|-- i386-randconfig-i015-20230524
|   `-- 
drivers-gpu-drm-i915-display-intel_display.c:error:unannotated-fall-through-between-switch-labels-Werror-Wimplicit-fallthrough
|-- i386-randconfig-i075-20230524
|   `-- 
drivers-gpu-drm-i915-display-intel_display.c:warning:unannotated-fall-through-between-switch-labels
|-- i386-randconfig-i085-20230524
|   `-- 
drivers-gpu-drm-i915-display-intel_display.c:warning:unannotated-fall-through-between-switch-labels
|-- x86_64-randconfig-x066-20230524
|   `-- 
drivers-gpu-drm-i915-display-intel_display.c:error:unannotated-fall-through-between-switch-labels-Werror-Wimplicit-fallthrough
`-- x86_64-randconfig-x072-20230525
`-- 
drivers-gpu-drm-i915-display-intel_display.c:warning:unannotated-fall-through-between-switch-labels

elapsed time: 725m

configs tested: 176
configs skipped: 10

tested configs:
alphaalldefconfig   gcc  
alpha 

Re: [Intel-gfx] [PATCH 3/6] drm/i915/uc/gsc: extract release and security versions from the gsc binary

[Ceraolo Spurio, Daniele]

On 5/24/2023 10:14 PM, Teres Alexis, Alan Previn wrote:

On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:


alan: snip



+int intel_gsc_fw_get_binary_info(struct intel_uc_fw *gsc_fw, const void *data, 
size_t size)
+{

alan:snip

+   /*
+* The GSC binary starts with the pointer layout, which contains the
+* locations of the various partitions of the binary. The one we're
+* interested in to get the version is the boot1 partition, where we can
+* find a BPDT header followed by entries, one of which points to the
+* RBE sub-section of the partition. From here, we can parse the CPD

alan: nit: could we add the meaning of 'RBE', probably not here but in the 
header file where GSC_RBE is defined?


I have no idea what RBE means, the specs just says to look for the 
section named that way. I didn't dig because we don't really care about 
its name, just that the CPD header is in there.



+* header and the following entries to find the manifest location
+* (entry identified by the "RBEP.man" name), from which we can finally
+* extract the version.
+*
+* --
+* [  intel_gsc_layout_pointers ]
+* [  ...   ]
+* [  boot1_offset  >---]--o
+* [  ...   ]  |
+* --  |
+* |
+* --  |
+* [  intel_gsc_bpdt_header ]<-o
+* --

alan: special thanks for the diagram - love these! :)
alan: snip


+   min_size = layout->boot1_offset + layout->boot1_offset > size;

alan: latter is a binary so + 1? or is this a typo and supposed to be:
min_size = layout->boot1_offset;


it's a cut & paste typo, it should be

min_size = layout->boot1_offset + layout->boot1_size;

thanks for spotting it.


actually since we are accessing a bpdt_header hanging off that offset, it 
should rather be:
min_size = layout->boot1_offset + sizeof(*bpdt_header);


I can add a check to make sure that boot1_size >= sizeof(*bpdt_header)


+   if (size < min_size) {
+   gt_err(gt, "GSC FW too small for boot section! %zu < %zu\n",
+  size, min_size);
+   return -ENODATA;
+   }
+
+   bpdt_header = data + layout->boot1_offset;
+   if (bpdt_header->signature != INTEL_GSC_BPDT_HEADER_SIGNATURE) {
+   gt_err(gt, "invalid signature for meu BPDT header: 0x%08x!\n",
+  bpdt_header->signature);
+   return -EINVAL;
+   }
+

alan: IIUC, to be strict about the size-crawl-checking, we should check minsize
again - this time with the additional "bpdt_header->descriptor_count * 
sizeof(*bpdt_entry)".
(hope i got that right?) - adding that check before parsing through the 
(bpdt_entry++)'s ->type


will do (same for the comments below)


+   bpdt_entry = (void *)bpdt_header + sizeof(*bpdt_header);
+   for (i = 0; i < bpdt_header->descriptor_count; i++, bpdt_entry++) {
+   if ((bpdt_entry->type & INTEL_GSC_BPDT_ENTRY_TYPE_MASK) !=
+   INTEL_GSC_BPDT_ENTRY_TYPE_GSC_RBE)
+   continue;
+
+   cpd_header = (void *)bpdt_header + 
bpdt_entry->sub_partition_offset;
+   break;
+   }
+
+   if (!cpd_header) {
+   gt_err(gt, "couldn't find CPD header in GSC binary!\n");
+   return -ENODATA;
+   }

alan: same as above, so for size-crawl-checking, we should check minsize again 
with the addition of cpd_header, no?

+
+   if (cpd_header->header_marker != INTEL_GSC_CPD_HEADER_MARKER) {
+   gt_err(gt, "invalid marker for meu CPD header in GSC bin: 
0x%08x!\n",
+  cpd_header->header_marker);
+   return -EINVAL;
+   }

alan: and again here, the size crawl checking with cpd_header->num_of_entries * 
*cpd_entry

+   cpd_entry = (void *)cpd_header + cpd_header->header_length;
+   for (i = 0; i < cpd_header->num_of_entries; i++, cpd_entry++) {
+   if (strcmp(cpd_entry->name, "RBEP.man") == 0) {
+   manifest = (void *)cpd_header + 
cpd_entry_offset(cpd_entry);
+   intel_uc_fw_version_from_meu_manifest(&gsc->release,
+ manifest);
+   gsc->security_version = manifest->security_version;
+   break;
+   }
+   }
+
+   return 0;

alan:snip

  
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h

index fff8928218df..8d7

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Allow user to set cache at BO creation (rev13)

[Patchwork]

== Series Details ==

Series: drm/i915: Allow user to set cache at BO creation (rev13)
URL   : https://patchwork.freedesktop.org/series/116870/
State : warning

== Summary ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix clang -Wimplicit-fallthrough in intel_async_flip_check_hw()

[Patchwork]

== Series Details ==

Series: drm/i915: Fix clang -Wimplicit-fallthrough in 
intel_async_flip_check_hw()
URL   : https://patchwork.freedesktop.org/series/118311/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_118311v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_118311v1_full:

### New IGT tests (275) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-1:
- Statuses : 3 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-1:
- Statuses : 3 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-d-hdmi-a-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-c-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-d-hdmi-a-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-hdmi-a-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-b-hdmi-a-2:
- Stat

Re: [Intel-gfx] [PATCH i-g-t] tests/i915/gem_ctx_persistence: Skip some subtests

[Kamil Konieczny]

Hi Vinay,

On 2023-05-24 at 12:19:06 -0700, Vinay Belgaumkar wrote:
> Hang and heartbeat subtests are not supported with GuC submission
> enabled.
> 
> Signed-off-by: Vinay Belgaumkar 
> ---
>  tests/i915/gem_ctx_persistence.c | 32 +++-
>  1 file changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/tests/i915/gem_ctx_persistence.c 
> b/tests/i915/gem_ctx_persistence.c
> index 42cf96329..1e122535e 100644
> --- a/tests/i915/gem_ctx_persistence.c
> +++ b/tests/i915/gem_ctx_persistence.c
> @@ -1366,19 +1366,25 @@ igt_main
>  
>   igt_subtest("hostile")
>   test_nohangcheck_hostile(i915, &empty_cfg);
> - igt_subtest("hang")
> - test_nohangcheck_hang(i915, &empty_cfg);
> -
> - igt_subtest("heartbeat-stop")
> - test_noheartbeat_many(i915, 1, 0);
> - igt_subtest("heartbeat-hang")
> - test_noheartbeat_many(i915, 1, IGT_SPIN_NO_PREEMPTION);
> - igt_subtest("heartbeat-many")
> - test_noheartbeat_many(i915, 16, 0);
> - igt_subtest("heartbeat-close")
> - test_noheartbeat_close(i915, 0);
> - igt_subtest("heartbeat-hostile")
> - test_noheartbeat_close(i915, IGT_SPIN_NO_PREEMPTION);
> +
> + igt_subtest_group {
> + igt_fixture
> + igt_skip_on(gem_using_guc_submission(i915));
--- ^^^
You cannot put this in fixture as there is no test defined in it.
Place skips at begin of test functions that need it.

Regards,
Kamil

> +
> + igt_subtest("hang")
> + test_nohangcheck_hang(i915, &empty_cfg);
> +
> + igt_subtest("heartbeat-stop")
> + test_noheartbeat_many(i915, 1, 0);
> + igt_subtest("heartbeat-hang")
> + test_noheartbeat_many(i915, 1, IGT_SPIN_NO_PREEMPTION);
> + igt_subtest("heartbeat-many")
> + test_noheartbeat_many(i915, 16, 0);
> + igt_subtest("heartbeat-close")
> + test_noheartbeat_close(i915, 0);
> + igt_subtest("heartbeat-hostile")
> + test_noheartbeat_close(i915, IGT_SPIN_NO_PREEMPTION);
> + }
>  
>   igt_subtest_group {
>   igt_fixture
> -- 
> 2.38.1
> 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Allow user to set cache at BO creation (rev12)

[Patchwork]

== Series Details ==

Series: drm/i915: Allow user to set cache at BO creation (rev12)
URL   : https://patchwork.freedesktop.org/series/116870/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_116870v12_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_116870v12_full:

### New IGT tests (283) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-2:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-c-hdmi-a-1:
- Statuses : 2 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-25@pipe-d-hdmi-a-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-5@pipe-c-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-hdmi-a-1:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-1:
- Statuses : 2 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-hdmi-a-2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-c-dp-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-c-hdmi-a-1:
- Statuses : 2 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-d-hdmi-a-1:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25:
- Statuses :
- Exec time: [None] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-dp-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-hdmi-a-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-b-dp-1:
-

[Intel-gfx] ✓ Fi.CI.BAT: success for Expose RPS thresholds in sysfs (rev3)

[Patchwork]

== Series Details ==

Series: Expose RPS thresholds in sysfs (rev3)
URL   : https://patchwork.freedesktop.org/series/117054/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187 -> Patchwork_117054v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 38)
--

  Additional (1): fi-tgl-1115g4 
  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([i915#3546] / [i915#7561])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][5] ([i915#7077])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html

  * igt@i915_selftest@live@execlists:
- fi-bsw-n3050:   [PASS][6] -> [ABORT][7] ([i915#7913])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [PASS][8] -> [ABORT][9] ([i915#4983] / [i915#7911] / 
[i915#7920])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4:  NOTRUN -> [INCOMPLETE][10] ([i915#7443] / [i915#8102])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_edid@dp-edid-read:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([i915#7828]) +7 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@kms_chamelium_e...@dp-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#4103]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([fdo#109285])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

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

  * igt@kms_psr@cursor_plane_move:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][15] ([fdo#110189]) +3 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@kms_psr@cursor_plane_move.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4579])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/fi-tgl-1115g4/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [DMESG-WARN][17] ([i915#7699]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@mman:
- bat-rpls-2: [TIMEOUT][19] ([i915#6794] / [i915#7392]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-rpls-2/igt@i915_selftest@l...@mman.html
   [20]: 
https://intel-gfx-

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gsc: use system include style for drm headers

[Patchwork]

== Series Details ==

Series: drm/i915/gsc: use system include style for drm headers
URL   : https://patchwork.freedesktop.org/series/118359/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187 -> Patchwork_118359v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 37)
--

  Additional (1): fi-tgl-1115g4 
  Missing(3): fi-kbl-soraka bat-jsl-1 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([i915#3546] / [i915#7561])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][5] ([i915#7077])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4:  NOTRUN -> [INCOMPLETE][6] ([i915#7443] / [i915#8102])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_edid@dp-edid-read:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][7] ([i915#7828]) +7 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@kms_chamelium_e...@dp-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#4103]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([fdo#109285])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][10] ([i915#1845] / [i915#5354]) +2 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_psr@cursor_plane_move:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][11] ([fdo#110189]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@kms_psr@cursor_plane_move.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#3555] / [i915#4579])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/fi-tgl-1115g4/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_selftest@live@guc:
- bat-rpls-1: [DMESG-WARN][13] ([i915#7852]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-rpls-1/igt@i915_selftest@l...@guc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/bat-rpls-1/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [DMESG-WARN][15] ([i915#7699]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@requests:
- {bat-mtlp-8}:   [DMESG-FAIL][17] ([i915#8497]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-mtlp-8/igt@i915_selftest@l...@requests.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- {bat-mtlp-6}:   [DMESG-WARN][19] ([i915#6367]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-mtlp-6/igt@i915_selftest@l...@slpc.html
   [20]: 
https://intel-gfx-ci.01.o

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix the disabling sequence for Bigjoiner

[Patchwork]

== Series Details ==

Series: drm/i915: Fix the disabling sequence for Bigjoiner
URL   : https://patchwork.freedesktop.org/series/118360/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187 -> Patchwork_118360v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 38)
--

  Additional (1): fi-tgl-1115g4 
  Missing(2): bat-mtlp-8 fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([i915#3546] / [i915#7561])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][5] ([i915#7077])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][6] ([i915#6367])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4:  NOTRUN -> [INCOMPLETE][7] ([i915#7443] / [i915#8102])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_edid@dp-edid-read:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][8] ([i915#7828]) +7 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@kms_chamelium_e...@dp-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][9] ([i915#4103]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][10] ([fdo#109285])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

  * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-dg2-11: NOTRUN -> [SKIP][11] ([i915#1845] / [i915#5354]) +2 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@read-crc:
- bat-adlp-9: NOTRUN -> [SKIP][12] ([i915#3546]) +1 similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html

  * igt@kms_psr@cursor_plane_move:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([fdo#110189]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@kms_psr@cursor_plane_move.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4579])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/fi-tgl-1115g4/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_selftest@live@guc:
- bat-rpls-1: [DMESG-WARN][15] ([i915#7852]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-rpls-1/igt@i915_selftest@l...@guc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/bat-rpls-1/igt@i915_selftest@l...@guc.html

  * igt@i915_selftest@live@migrate:
- bat-dg2-11: [DMESG-WARN][17] ([i915#7699]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@mman:
- bat-rpls-2: [TIMEOUT][19] ([i915#6794] / [i915#7392]) -> 
[PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/

[Intel-gfx] ✓ Fi.CI.BAT: success for Add rc_range_params for YUV420 (rev3)

[Patchwork]

== Series Details ==

Series: Add rc_range_params for YUV420 (rev3)
URL   : https://patchwork.freedesktop.org/series/118204/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187 -> Patchwork_118204v3


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 38)
--

  Additional (1): fi-tgl-1115g4 
  Missing(2): fi-kbl-soraka fi-snb-2520m 

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@basic-hwmon:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][1] ([i915#7456])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html

  * igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][2] ([i915#2190])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html

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

  * igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][4] ([i915#3546] / [i915#7561])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html

  * igt@i915_pm_backlight@basic-brightness@edp-1:
- bat-rplp-1: NOTRUN -> [ABORT][5] ([i915#7077])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/bat-rplp-1/igt@i915_pm_backlight@basic-brightn...@edp-1.html

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

  * igt@i915_selftest@live@requests:
- bat-dg2-11: [PASS][8] -> [ABORT][9] ([i915#7913])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/bat-dg2-11/igt@i915_selftest@l...@requests.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/bat-dg2-11/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@reset:
- bat-rpls-2: NOTRUN -> [ABORT][10] ([i915#4983] / [i915#7461] / 
[i915#7913] / [i915#8347])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/bat-rpls-2/igt@i915_selftest@l...@reset.html

  * igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4:  NOTRUN -> [INCOMPLETE][11] ([i915#7443] / [i915#8102])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html

  * igt@kms_chamelium_edid@dp-edid-read:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][12] ([i915#7828]) +7 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@kms_chamelium_e...@dp-edid-read.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][14] ([fdo#109285])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html

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

  * igt@kms_pipe_crc_basic@read-crc:
- bat-adlp-9: NOTRUN -> [SKIP][16] ([i915#3546]) +1 similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html

  * igt@kms_psr@cursor_plane_move:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][17] ([fdo#110189]) +3 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@kms_psr@cursor_plane_move.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-1115g4:  NOTRUN -> [SKIP][18] ([i915#3555] / [i915#4579])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/fi-tgl-1115g4/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_selftest@live@mman:
- bat-rpls-2: [TIMEOUT][19] ([i915#6794] / [i915#7392]) -> 
[PASS][20]
   [19]: 
https

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow user to set cache at BO creation (rev13)

[Patchwork]

== Series Details ==

Series: drm/i915: Allow user to set cache at BO creation (rev13)
URL   : https://patchwork.freedesktop.org/series/116870/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13188 -> Patchwork_116870v13


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 39)
--

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_exec_parallel@engines@userptr:
- {bat-mtlp-6}:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13188/bat-mtlp-6/igt@gem_exec_parallel@engi...@userptr.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/bat-mtlp-6/igt@gem_exec_parallel@engi...@userptr.html

  
Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_mmap_gtt@basic:
- bat-dg2-9:  NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/bat-dg2-9/igt@gem_mmap_...@basic.html

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

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg2-9:  NOTRUN -> [SKIP][6] ([i915#5354] / [i915#7561])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/bat-dg2-9/igt@i915_pm_backli...@basic-brightness.html

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

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

  * igt@i915_selftest@live@requests:
- bat-rpls-1: [PASS][12] -> [ABORT][13] ([i915#4983] / [i915#7911] 
/ [i915#7920])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13188/bat-rpls-1/igt@i915_selftest@l...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/bat-rpls-1/igt@i915_selftest@l...@requests.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][14] ([i915#6367])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][15] ([i915#6687])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][17] ([i915#4212]) +2 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/bat-dg2-9/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][18] ([i915#4215] / [i915#5190])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/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][19] ([IGT#6] / [i915#4212]) +4 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116870v13/bat-dg2-9/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_chamelium_hpd@common-hpd-after-s

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/mtl/huc: Use the media gt for the HuC getparam

[John Harrison]

On 4/28/2023 11:58, Daniele Ceraolo Spurio wrote:

On MTL, for obvious reasons, HuC is only available on the media tile.
We already disable SW support for HuC on the root gt due to the
absence of VCS engines, but we also need to update the getparam to point
to the HuC struct in the media GT.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: John Harrison 
---
  drivers/gpu/drm/i915/i915_getparam.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 2238e096c957..7aa47550e4f2 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -98,7 +98,11 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
value = sseu->min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
-   value = intel_huc_check_status(&to_gt(i915)->uc.huc);
+   /* On platform with a media GT, the HuC is on that GT */
+   if (i915->media_gt)
+   value = intel_huc_check_status(&i915->media_gt->uc.huc);
+   else
+   value = intel_huc_check_status(&to_gt(i915)->uc.huc);
I assume the intention is to ignore multi-tile complications? As in, all 
tiles are guaranteed to be the same so there is no point looking beyond 
the root tile?


Reviewed-by: John Harrison 



if (value < 0)
return value;
break;

Re: [Intel-gfx] [PATCH v2 8/8] drm/i915/huc: define HuC FW version for MTL

[John Harrison]

On 4/28/2023 11:58, Daniele Ceraolo Spurio wrote:

Follow the same logic as DG2, so just a meu binary with no version number.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 

Reviewed-by: John Harrison 


---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 3338dd45e78b..796f54a62eef 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -102,6 +102,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
fw_def(SKYLAKE,  0, guc_mmp(skl,  70, 1, 1))
  
  #define INTEL_HUC_FIRMWARE_DEFS(fw_def, huc_raw, huc_mmp, huc_gsc) \

+   fw_def(METEORLAKE,   0, huc_gsc(mtl)) \
fw_def(DG2,  0, huc_gsc(dg2)) \
fw_def(ALDERLAKE_P,  0, huc_raw(tgl)) \
fw_def(ALDERLAKE_P,  0, huc_mmp(tgl,  7, 9, 3)) \

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pmu: couple of cleanups (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/pmu: couple of cleanups (rev2)
URL   : https://patchwork.freedesktop.org/series/118225/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_118225v2_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_118225v2_full:

### New IGT tests (5) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl:  [PASS][1] -> [FAIL][2] ([i915#2842])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-apl4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-apl1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

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

  * igt@gem_lmem_swapping@basic:
- shard-glk:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-glk3/igt@gem_lmem_swapp...@basic.html

  * igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-snb:  [PASS][5] -> [INCOMPLETE][6] ([i915#8295])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-snb6/igt@gem_pp...@blt-vs-render-ctx0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-snb1/igt@gem_pp...@blt-vs-render-ctx0.html

  * igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-glk3/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs:
- shard-glk:  NOTRUN -> [SKIP][8] ([fdo#109271]) +15 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-glk3/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu:
- shard-glk:  NOTRUN -> [SKIP][9] ([IGT#6] / [fdo#109271]) +10 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-glk3/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html

  * 
igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4579]) +11 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-snb1/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0...@pipe-b-hdmi-a-1.html

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0-25@pipe-a-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][11] ([fdo#109271]) +12 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-snb1/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0...@pipe-a-hdmi-a-1.html

  * igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-c-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4579]) +2 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-glk3/igt@kms_plane_scaling@planes-downscale-factor-0...@pipe-c-hdmi-a-1.html

  
 Possible fixes 

  * igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][13] ([i915#7742]) -> [PASS][14] +1 similar 
issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-rkl-7/igt@drm_fdinfo@i...@rcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118225v2/shard-rkl-6/igt@drm_fdinfo@i...@rcs0.html

  * igt@gem_exec_fair@basic-none@bcs0:
- {shard-rkl}:[FAIL][15] ([i915#2842]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-rkl-1/igt@gem_exec_fair@basic-n...@bcs0.html
   [16]: 
https://i

Re: [Intel-gfx] [PATCH v2 2/7] drm/i915: Expose crtc CTM property on ilk/snb

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville 
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 2/7] drm/i915: Expose crtc CTM property on 
> ilk/snb
> 
> From: Ville Syrjälä 
> 
> The ilk/snb code is internally fully capable of handling the CTM property, so 
> expose
> it.
> 
> Note that we still choose not to expose DEGAMMA_LUT though.
> The hardware is capable if degamma or gamma, but not both similtanously due to

Nit: Typo in "simultaneously"

Looks Good to me.
Reviewed-by: Uma Shankar 

> lack of the split gamma mode. Exposing both LUTs might encourage userspace to 
> try
> enabling both at the same time.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 07f1afe1d406..4fc16cac052d 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -3473,7 +3473,7 @@ void intel_color_crtc_init(struct intel_crtc *crtc)
> 
>   gamma_lut_size = INTEL_INFO(i915)->display.color.gamma_lut_size;
>   degamma_lut_size = INTEL_INFO(i915)->display.color.degamma_lut_size;
> - has_ctm = degamma_lut_size != 0;
> + has_ctm = DISPLAY_VER(i915) >= 5 && !IS_VALLEYVIEW(i915);
> 
>   /*
>* "DPALETTE_A: NOTE: The 8-bit (non-10-bit) mode is the
> --
> 2.39.2

Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling

[Shankar, Uma]

> -Original Message-
> From: dri-devel  On Behalf Of Ville 
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
> 
> From: Ville Syrjälä 
> 
> The CHV CGM CSC coefficients are in s4.12 two's complement format. Fix the 
> CTM-
> >CGM conversion to handle that correctly instead of pretending that the hw
> coefficients are also in some sign-magnitude format.

Spec is slightly confusing when it says:
"CGM CSC :  Input pixels to the CGM CSC are 14 bits. (u.14 format). 
Coefficients are 16 bits (s3.12)."
Also here:
"Programmable parameters : 
c0[15 :0], c1[15 :0], c2[15 :0], c3[15 :0], c4[15 :0], c5[15 :0], c6[15 :0], 
c7[15 :0], c8[15 :0] ; // signed matrix coefficients  (s3.12)"

But the coefficients are 16bits, can you help understand how were you able to 
crack this 😊

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 46 ++
>  1 file changed, 29 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 4fc16cac052d..63141f4ed372 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
> intel_crtc_state *crtc_state)
>   icl_update_output_csc(crtc, &crtc_state->output_csc);  }
> 
> +static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int
> +frac_bits) {
> + s64 c = CTM_COEFF_ABS(coeff);
> +
> + /* leave an extra bit for rounding */
> + c >>= 32 - frac_bits - 1;
> +
> + /* round and drop the extra bit */
> + c = (c + 1) >> 1;
> +
> + if (CTM_COEFF_NEGATIVE(coeff))
> + c = -c;
> +
> + c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
> +   (s64)(BIT(int_bits + frac_bits - 1) - 1));
> +
> + return c & (BIT(int_bits + frac_bits) - 1); }
> +
> +/*
> + * CHV Color Gamut Mapping (CGM) CSC
> + * |r|   | c0 c1 c2 |   |r|
> + * |g| = | c3 c4 c5 | x |g|
> + * |b|   | c6 c7 c8 |   |b|
> + *
> + * Coefficients are two's complement s4.12.
> + */
>  static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state 
> *crtc_state,
>   struct intel_csc_matrix *csc)
>  {
>   const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
>   int i;
> 
> - for (i = 0; i < 9; i++) {
> - u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
> -
> - /* Round coefficient. */
> - abs_coeff += 1 << (32 - 13);
> - /* Clamp to hardware limits. */
> - abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
> -
> - csc->coeff[i] = 0;
> -
> - /* Write coefficients in S3.12 format. */
> - if (ctm->matrix[i] & (1ULL << 63))
> - csc->coeff[i] |= 1 << 15;
> -
> - csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
> - csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
> - }
> + for (i = 0; i < 9; i++)
> + csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
>  }
> 
>  static void chv_load_cgm_csc(struct intel_crtc *crtc,
> --
> 2.39.2

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: Always enable CGM CSC on CHV

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville 
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 4/7] drm/i915: Always enable CGM CSC on CHV
> 
> From: Ville Syrjälä 
> 
> On CHV toggling the CGM CSC on/off while the pipe is running leads to 
> underruns.
> Looks like we'd have to do the toggling strictly inside the start_of_vblank-
> frame_start window to avoid this, but that window is less than a scanline so 
> there's
> no way we can guarantee hitting it.
> 
> As a workaround let's just leave the CGM CSC permanently enabled.
> Fortunately the CGM gamma/degamma units don't seem to suffer from this malady.
> 
> I also tried turning off CGM unit clock gating, but that did not help.

Looks Good to me.
Reviewed-by: Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 63141f4ed372..7a705e7d8776 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -605,6 +605,16 @@ static void chv_cgm_csc_convert_ctm(const struct
> intel_crtc_state *crtc_state,
>   csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);  
> }
> 
> +#define CHV_CGM_CSC_COEFF_1_0 (1 << 12)
> +
> +static const struct intel_csc_matrix chv_cgm_csc_matrix_identity = {
> + .coeff = {
> + CHV_CGM_CSC_COEFF_1_0, 0, 0,
> + 0, CHV_CGM_CSC_COEFF_1_0, 0,
> + 0, 0, CHV_CGM_CSC_COEFF_1_0,
> + },
> +};
> +
>  static void chv_load_cgm_csc(struct intel_crtc *crtc,
>const struct intel_csc_matrix *csc)  { @@ -667,9 
> +677,9
> @@ static void chv_assign_csc(struct intel_crtc_state *crtc_state)
> 
>   chv_cgm_csc_convert_ctm(crtc_state, &crtc_state->csc);
>   } else {
> - drm_WARN_ON(&i915->drm, (crtc_state->cgm_mode &
> CGM_PIPE_MODE_CSC) != 0);
> + drm_WARN_ON(&i915->drm, (crtc_state->cgm_mode &
> CGM_PIPE_MODE_CSC) ==
> +0);
> 
> - intel_csc_clear(&crtc_state->csc);
> + crtc_state->csc = chv_cgm_csc_matrix_identity;
>   }
>  }
> 
> @@ -2033,6 +2043,13 @@ static u32 chv_cgm_mode(const struct intel_crtc_state
> *crtc_state)
>   !lut_is_legacy(crtc_state->hw.gamma_lut))
>   cgm_mode |= CGM_PIPE_MODE_GAMMA;
> 
> + /*
> +  * Toggling the CGM CSC on/off outside of the tiny window
> +  * between start of vblank and frame start causes underruns.
> +  * Always enable the CGM CSC as a workaround.
> +  */
> + cgm_mode |= CGM_PIPE_MODE_CSC;
> +
>   return cgm_mode;
>  }
> 
> --
> 2.39.2

[Intel-gfx] ✗ Fi.CI.IGT: failure for mtl: add support for pmdemand (rev8)

[Patchwork]

== Series Details ==

Series: mtl: add support for pmdemand (rev8)
URL   : https://patchwork.freedesktop.org/series/116949/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_116949v8_full


Summary
---

  **FAILURE**

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

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@prime_busy@hang@vcs0:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk8/igt@prime_busy@h...@vcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v8/shard-glk8/igt@prime_busy@h...@vcs0.html

  
New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_116949v8_full:

### New IGT tests (7) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@gem_lmem_swapping@basic:
- shard-glk:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v8/shard-glk3/igt@gem_lmem_swapp...@basic.html

  * igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v8/shard-glk3/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs:
- shard-glk:  NOTRUN -> [SKIP][6] ([fdo#109271]) +15 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v8/shard-glk3/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu:
- shard-glk:  NOTRUN -> [SKIP][7] ([IGT#6] / [fdo#109271]) +10 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v8/shard-glk3/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html

  * 
igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-rotation@pipe-b-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4579]) +11 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v8/shard-snb1/igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-rotat...@pipe-b-hdmi-a-1.html

  * igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-c-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4579]) +2 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v8/shard-glk3/igt@kms_plane_scaling@planes-downscale-factor-0...@pipe-c-hdmi-a-1.html

  * 
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-a-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][10] ([fdo#109271]) +14 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116949v8/shard-snb1/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0...@pipe-a-hdmi-a-1.html

  
 Possible fixes 

  * igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][11] ([i915#6268]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-rkl-1/ig

[Intel-gfx] [PATCH] drm/i915: use localized __diag_ignore_all() instead of per file

[Jani Nikula]

Use localized __diag_push(), __diag_ignore_all() with rationale, and
__diag_pop() for specific initializations instead of blanket disabling
of -Woverride-init across several files.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/Makefile   | 5 -
 drivers/gpu/drm/i915/display/intel_display_device.c | 5 +
 drivers/gpu/drm/i915/display/intel_fbdev.c  | 5 +
 drivers/gpu/drm/i915/i915_pci.c | 5 +
 4 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 06374fc072d3..1c9ed4c52760 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -23,11 +23,6 @@ subdir-ccflags-y += $(call cc-disable-warning, 
unused-but-set-variable)
 subdir-ccflags-y += $(call cc-disable-warning, frame-address)
 subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
 
-# Fine grained warnings disable
-CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
-CFLAGS_display/intel_display_device.o = $(call cc-disable-warning, 
override-init)
-CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)
-
 subdir-ccflags-y += -I$(srctree)/$(src)
 
 # Please keep these build lists sorted!
diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c 
b/drivers/gpu/drm/i915/display/intel_display_device.c
index a513ac8f71a3..464df1764a86 100644
--- a/drivers/gpu/drm/i915/display/intel_display_device.c
+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
@@ -14,6 +14,9 @@
 #include "intel_display_reg_defs.h"
 #include "intel_fbc.h"
 
+__diag_push();
+__diag_ignore_all("-Woverride-init", "Allow overriding inherited members");
+
 static const struct intel_display_device_info no_display = {};
 
 #define PIPE_A_OFFSET  0x7
@@ -650,6 +653,8 @@ static const struct intel_display_device_info 
xe_lpdp_display = {
BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
 };
 
+__diag_pop();
+
 #undef INTEL_VGA_DEVICE
 #undef INTEL_QUANTA_VGA_DEVICE
 #define INTEL_VGA_DEVICE(id, info) { id, info }
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index aab1ae74a8f7..2c3f7befed17 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -130,6 +130,9 @@ static int intel_fbdev_mmap(struct fb_info *info, struct 
vm_area_struct *vma)
return i915_gem_fb_mmap(obj, vma);
 }
 
+__diag_push();
+__diag_ignore_all("-Woverride-init", "Allow overriding the default ops");
+
 static const struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
@@ -144,6 +147,8 @@ static const struct fb_ops intelfb_ops = {
.fb_mmap = intel_fbdev_mmap,
 };
 
+__diag_pop();
+
 static int intelfb_alloc(struct drm_fb_helper *helper,
 struct drm_fb_helper_surface_size *sizes)
 {
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 928975d5fe2f..3d7a5db9833b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -38,6 +38,9 @@
 #include "i915_reg.h"
 #include "intel_pci_config.h"
 
+__diag_push();
+__diag_ignore_all("-Woverride-init", "Allow overriding inherited members");
+
 #define PLATFORM(x) .platform = (x)
 #define GEN(x) \
.__runtime.graphics.ip.ver = (x), \
@@ -843,6 +846,8 @@ static const struct intel_device_info mtl_info = {
 
 #undef PLATFORM
 
+__diag_pop();
+
 /*
  * Make sure any device matches here are from most specific to most
  * general.  For example, since the Quanta match is based on the subsystem
-- 
2.39.2

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: Implement CTM property support for VLV

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville 
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 5/7] drm/i915: Implement CTM property support 
> for
> VLV
> 
> From: Ville Syrjälä 
> 
> VLV has a so called "wide gamut color correction" unit (WGC).
> What it is is a 3x3 matrix similar to the later CHV CGM CSC, which less
> precisions/range. In fact CHV also has the WGC but using it there doesn't 
> reall make
> sense when you have the superior CGM CSC around.
> 
> Hook up the necessary stuff to expose the WGC as the CTM crtc property.
> 
> One additional crazy idea that came to mind would be to use the WGC as an 
> output
> CSC on CHV for YCbCr output. But it would be incompatible with the legacy LUT
> usage. In fact since the WGC lacks post-offsets we'd probably have to use the 
> legacy
> LUT to do that final part of the RGB->YCbCr conversion. Sounds doable, but 
> perhaps
> not worth the hassle.

Yeah WGC on CHV was just kept for safety against any hw issue, with plan to 
drop in future platforms.
Exposing it for VLV is nice.

Changes look good to me.
Reviewed-by:  Uma Shankar 

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_color.c| 170 +-
>  .../drm/i915/display/intel_crtc_state_dump.c  |   6 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |   8 +
>  .../drm/i915/display/intel_display_types.h|   3 +
>  drivers/gpu/drm/i915/i915_reg.h   |  15 ++
>  5 files changed, 198 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 7a705e7d8776..e36d8c248b84 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -587,6 +587,98 @@ static u16 ctm_to_twos_complement(u64 coeff, int
> int_bits, int frac_bits)
>   return c & (BIT(int_bits + frac_bits) - 1);  }
> 
> +/*
> + * VLV/CHV Wide Gamut Color Correction (WGC) CSC
> + * |r|   | c0 c1 c2 |   |r|
> + * |g| = | c3 c4 c5 | x |g|
> + * |b|   | c6 c7 c8 |   |b|
> + *
> + * Coefficients are two's complement s2.10.
> + */
> +static void vlv_wgc_csc_convert_ctm(const struct intel_crtc_state 
> *crtc_state,
> + struct intel_csc_matrix *csc)
> +{
> + const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
> + int i;
> +
> + for (i = 0; i < 9; i++)
> + csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 2, 10); }
> +
> +static void vlv_load_wgc_csc(struct intel_crtc *crtc,
> +  const struct intel_csc_matrix *csc) {
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> +
> + intel_de_write_fw(dev_priv, PIPE_WGC_C01_C00(pipe),
> +   csc->coeff[1] << 16 | csc->coeff[0]);
> + intel_de_write_fw(dev_priv, PIPE_WGC_C02(pipe),
> +   csc->coeff[2]);
> +
> + intel_de_write_fw(dev_priv, PIPE_WGC_C11_C10(pipe),
> +   csc->coeff[4] << 16 | csc->coeff[3]);
> + intel_de_write_fw(dev_priv, PIPE_WGC_C12(pipe),
> +   csc->coeff[5]);
> +
> + intel_de_write_fw(dev_priv, PIPE_WGC_C21_C20(pipe),
> +   csc->coeff[7] << 16 | csc->coeff[6]);
> + intel_de_write_fw(dev_priv, PIPE_WGC_C22(pipe),
> +   csc->coeff[8]);
> +}
> +
> +static void vlv_read_wgc_csc(struct intel_crtc *crtc,
> +  struct intel_csc_matrix *csc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
> + u32 tmp;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C01_C00(pipe));
> + csc->coeff[0] = tmp & 0x;
> + csc->coeff[1] = tmp >> 16;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C02(pipe));
> + csc->coeff[2] = tmp & 0x;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C11_C10(pipe));
> + csc->coeff[3] = tmp & 0x;
> + csc->coeff[4] = tmp >> 16;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C12(pipe));
> + csc->coeff[5] = tmp & 0x;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C21_C20(pipe));
> + csc->coeff[6] = tmp & 0x;
> + csc->coeff[7] = tmp >> 16;
> +
> + tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C22(pipe));
> + csc->coeff[8] = tmp & 0x;
> +}
> +
> +static void vlv_read_csc(struct intel_crtc_state *crtc_state) {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> +
> + if (crtc_state->wgc_enable)
> + vlv_read_wgc_csc(crtc, &crtc_state->csc); }
> +
> +static void vlv_assign_csc(struct intel_crtc_state *crtc_state) {
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> +
> + if (crtc_state->hw.ctm) {
> + drm_WARN_ON(&i915->drm, !crtc_state-

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3 parts

[Shankar, Uma]

> -Original Message-
> From: Intel-gfx  On Behalf Of Ville 
> Syrjala
> Sent: Thursday, April 13, 2023 10:19 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3 
> parts
> 
> From: Ville Syrjälä 
> 
> Apparently desktop gen3 parts don't support the 10bit gamma mode at all. Stop
> claiming otherwise.
> 
> As is the case with pipe A on gen3 mobile parts, the PIPECONF gamma mode bit 
> can
> be set but it has no effect on the output.
> 
> PNV seems to be the only slight exception, but generally the desktop PNV 
> variant
> looks more like a mobile part so this is not entirely surprising.

Couldn't check the relevant spec to re-confirm, trusting your judgment here.
Reviewed-by: Uma Shankar 

> Fixes: 67630bacae23 ("drm/i915: Add 10bit gamma mode for gen2/3")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> b/drivers/gpu/drm/i915/i915_pci.c index
> cddb6e197972..305c05c3f93b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -250,13 +250,13 @@ static const struct intel_device_info i865g_info = {
>   .dma_mask_size = 32, \
>   I9XX_PIPE_OFFSETS, \
>   I9XX_CURSOR_OFFSETS, \
> - I9XX_COLORS, \
>   GEN_DEFAULT_PAGE_SIZES, \
>   GEN_DEFAULT_REGIONS
> 
>  static const struct intel_device_info i915g_info = {
>   GEN3_FEATURES,
>   PLATFORM(INTEL_I915G),
> + I845_COLORS,
>   .has_coherent_ggtt = false,
>   .display.cursor_needs_physical = 1,
>   .display.has_overlay = 1,
> @@ -268,6 +268,7 @@ static const struct intel_device_info i915g_info = {  
> static
> const struct intel_device_info i915gm_info = {
>   GEN3_FEATURES,
>   PLATFORM(INTEL_I915GM),
> + I9XX_COLORS,
>   .is_mobile = 1,
>   .display.cursor_needs_physical = 1,
>   .display.has_overlay = 1,
> @@ -281,6 +282,7 @@ static const struct intel_device_info i915gm_info = {  
> static
> const struct intel_device_info i945g_info = {
>   GEN3_FEATURES,
>   PLATFORM(INTEL_I945G),
> + I845_COLORS,
>   .display.has_hotplug = 1,
>   .display.cursor_needs_physical = 1,
>   .display.has_overlay = 1,
> @@ -292,6 +294,7 @@ static const struct intel_device_info i945g_info = {  
> static
> const struct intel_device_info i945gm_info = {
>   GEN3_FEATURES,
>   PLATFORM(INTEL_I945GM),
> + I9XX_COLORS,
>   .is_mobile = 1,
>   .display.has_hotplug = 1,
>   .display.cursor_needs_physical = 1,
> @@ -306,6 +309,7 @@ static const struct intel_device_info i945gm_info = {  
> static
> const struct intel_device_info g33_info = {
>   GEN3_FEATURES,
>   PLATFORM(INTEL_G33),
> + I845_COLORS,
>   .display.has_hotplug = 1,
>   .display.has_overlay = 1,
>   .dma_mask_size = 36,
> @@ -314,6 +318,7 @@ static const struct intel_device_info g33_info = {  static
> const struct intel_device_info pnv_g_info = {
>   GEN3_FEATURES,
>   PLATFORM(INTEL_PINEVIEW),
> + I9XX_COLORS,
>   .display.has_hotplug = 1,
>   .display.has_overlay = 1,
>   .dma_mask_size = 36,
> @@ -322,6 +327,7 @@ static const struct intel_device_info pnv_g_info = {  
> static
> const struct intel_device_info pnv_m_info = {
>   GEN3_FEATURES,
>   PLATFORM(INTEL_PINEVIEW),
> + I9XX_COLORS,
>   .is_mobile = 1,
>   .display.has_hotplug = 1,
>   .display.has_overlay = 1,
> --
> 2.39.2

Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling

[Shankar, Uma]

> -Original Message-
> From: Shankar, Uma
> Sent: Friday, May 26, 2023 2:25 AM
> To: Ville Syrjala ; 
> intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: RE: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign 
> handling
> 
> 
> 
> > -Original Message-
> > From: dri-devel  On Behalf Of
> > Ville Syrjala
> > Sent: Thursday, April 13, 2023 10:19 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org
> > Subject: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign
> > handling
> >
> > From: Ville Syrjälä 
> >
> > The CHV CGM CSC coefficients are in s4.12 two's complement format. Fix
> > the CTM-
> > >CGM conversion to handle that correctly instead of pretending that
> > >the hw
> > coefficients are also in some sign-magnitude format.
> 
> Spec is slightly confusing when it says:
> "CGM CSC :  Input pixels to the CGM CSC are 14 bits. (u.14 format). 
> Coefficients are
> 16 bits (s3.12)."
> Also here:
> "Programmable parameters :
> c0[15 :0], c1[15 :0], c2[15 :0], c3[15 :0], c4[15 :0], c5[15 :0], c6[15 :0], 
> c7[15 :0],
> c8[15 :0] ; // signed matrix coefficients  (s3.12)"
> 
> But the coefficients are 16bits, can you help understand how were you able to 
> crack
> this 😊

I think I got it. Looks good to me.
Reviewed-by: Uma Shankar 

> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 46
> > ++
> >  1 file changed, 29 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 4fc16cac052d..63141f4ed372 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
> > intel_crtc_state *crtc_state)
> > icl_update_output_csc(crtc, &crtc_state->output_csc);  }
> >
> > +static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int
> > +frac_bits) {
> > +   s64 c = CTM_COEFF_ABS(coeff);
> > +
> > +   /* leave an extra bit for rounding */
> > +   c >>= 32 - frac_bits - 1;
> > +
> > +   /* round and drop the extra bit */
> > +   c = (c + 1) >> 1;
> > +
> > +   if (CTM_COEFF_NEGATIVE(coeff))
> > +   c = -c;
> > +
> > +   c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
> > + (s64)(BIT(int_bits + frac_bits - 1) - 1));
> > +
> > +   return c & (BIT(int_bits + frac_bits) - 1); }
> > +
> > +/*
> > + * CHV Color Gamut Mapping (CGM) CSC
> > + * |r|   | c0 c1 c2 |   |r|
> > + * |g| = | c3 c4 c5 | x |g|
> > + * |b|   | c6 c7 c8 |   |b|
> > + *
> > + * Coefficients are two's complement s4.12.
> > + */
> >  static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state 
> > *crtc_state,
> > struct intel_csc_matrix *csc)  {
> > const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
> > int i;
> >
> > -   for (i = 0; i < 9; i++) {
> > -   u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
> > -
> > -   /* Round coefficient. */
> > -   abs_coeff += 1 << (32 - 13);
> > -   /* Clamp to hardware limits. */
> > -   abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
> > -
> > -   csc->coeff[i] = 0;
> > -
> > -   /* Write coefficients in S3.12 format. */
> > -   if (ctm->matrix[i] & (1ULL << 63))
> > -   csc->coeff[i] |= 1 << 15;
> > -
> > -   csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
> > -   csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
> > -   }
> > +   for (i = 0; i < 9; i++)
> > +   csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
> >  }
> >
> >  static void chv_load_cgm_csc(struct intel_crtc *crtc,
> > --
> > 2.39.2

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: use localized __diag_ignore_all() instead of per file

[Patchwork]

== Series Details ==

Series: drm/i915: use localized __diag_ignore_all() instead of per file
URL   : https://patchwork.freedesktop.org/series/118395/
State : warning

== Summary ==

Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/display/intel_display_device.c:468:9: warning: 
Initializer entry defined twice
+drivers/gpu/drm/i915/display/intel_display_device.c:470:9:   also defined here
+drivers/gpu/drm/i915/display/intel_display_device.c:565:9: warning: 
Initializer entry defined twice
+drivers/gpu/drm/i915/display/intel_display_device.c:570:10:   also defined here
+drivers/gpu/drm/i915/display/intel_display_device.c:576:9: warning: 
Initializer entry defined twice
+drivers/gpu/drm/i915/display/intel_display_device.c:578:10:   also defined here
+drivers/gpu/drm/i915/display/intel_display_device.c:645:9: warning: 
Initializer entry defined twice
+drivers/gpu/drm/i915/display/intel_display_device.c:649:10:   also defined here
+drivers/gpu/drm/i915/display/intel_fbdev.c:138:9: warning: Initializer entry 
defined twice
+drivers/gpu/drm/i915/display/intel_fbdev.c:139:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:154:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:156:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:185:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:187:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:191:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:193:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:197:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:200:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:217:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:220:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:224:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:228:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:232:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:235:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:239:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:243:10:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:408:9:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:408:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:413:9:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:413:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:418:9:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:418:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:436:9:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:436:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:441:9:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:441:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:446:9:   also defined here
+drivers/gpu/drm/i915/i915_pci.c:446:9: warning: Initializer entry defined twice
+drivers/gpu/drm/i915/i915_pci.c:454:9: warning: too many warnings

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: use localized __diag_ignore_all() instead of per file

[Patchwork]

== Series Details ==

Series: drm/i915: use localized __diag_ignore_all() instead of per file
URL   : https://patchwork.freedesktop.org/series/118395/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13188 -> Patchwork_118395v1


Summary
---

  **SUCCESS**

  No regressions found.

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

Participating hosts (39 -> 38)
--

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

Known issues


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

### IGT changes ###

 Issues hit 

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

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

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

  * igt@i915_pm_backlight@basic-brightness:
- bat-dg2-9:  NOTRUN -> [SKIP][4] ([i915#5354] / [i915#7561])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-dg2-9/igt@i915_pm_backli...@basic-brightness.html

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

  * igt@i915_selftest@live@migrate:
- bat-adlp-9: [PASS][6] -> [DMESG-FAIL][7] ([i915#7699] / 
[i915#7913])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13188/bat-adlp-9/igt@i915_selftest@l...@migrate.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-adlp-9/igt@i915_selftest@l...@migrate.html
- bat-dg2-11: [PASS][8] -> [DMESG-WARN][9] ([i915#7699])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13188/bat-dg2-11/igt@i915_selftest@l...@migrate.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html

  * igt@i915_selftest@live@slpc:
- bat-rpls-2: NOTRUN -> [DMESG-WARN][10] ([i915#6367])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html

  * igt@i915_suspend@basic-s2idle-without-i915:
- bat-rpls-2: NOTRUN -> [ABORT][11] ([i915#6687])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-rpls-2/igt@i915_susp...@basic-s2idle-without-i915.html

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

  * igt@kms_addfb_basic@basic-x-tiled-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][13] ([i915#4212]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-dg2-9/igt@kms_addfb_ba...@basic-x-tiled-legacy.html

  * igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][14] ([i915#4215] / [i915#5190])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/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][15] ([IGT#6] / [i915#4212]) +4 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-dg2-9/igt@kms_addfb_ba...@framebuffer-vs-set-tiling.html

  * igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-glk-j4005:   NOTRUN -> [SKIP][16] ([fdo#109271])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/fi-glk-j4005/igt@kms_chamelium_...@common-hpd-after-suspend.html

  * igt@kms_chamelium_hpd@vga-hpd-fast:
- bat-dg2-9:  NOTRUN -> [SKIP][17] ([i915#7828]) +8 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-dg2-9/igt@kms_chamelium_...@vga-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg2-9:  NOTRUN -> [SKIP][18] ([IGT#6] / [i915#4103] / 
[i915#4213]) +1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118395v1/bat-dg2-9/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

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

  * i

Re: [Intel-gfx] [PATCH 3/6] drm/i915/uc/gsc: extract release and security versions from the gsc binary

[Teres Alexis, Alan Previn]

On Thu, 2023-05-25 at 09:56 -0700, Ceraolo Spurio, Daniele wrote:
> On 5/24/2023 10:14 PM, Teres Alexis, Alan Previn wrote:
> > On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:
alan:snip
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
> > > @@ -17,6 +17,9 @@ struct intel_gsc_uc {
> > >   struct intel_uc_fw fw;
> > > 
> > >   /* GSC-specific additions */
> > > + struct intel_uc_fw_ver release;
> > > + u32 security_version;
> > alan: for consistency and less redundancy, can't we add "security_version"
> > into 'struct intel_uc_fw_ver' (which is zero for firmware that doesn't
> > have it). That way, intel_gsc_uc can re-use intel_uc_fw.file_selected
> > just like huc?
> 
> I'm not sure what you mean by re-using intel_uc_fw.file_selected. Is 
> that for the call from intel_uc_fw_version_from_meu_manifest? I'm 
> purposely not doing that. Note that the GSC has 3 versions:
> 
> Release version (incremented with each build and encoded in the header)
> Security version (also encoded in the header)
> Compatibility version (queried via message to the GSC)
> 
> The one we care about for communicating with the GSC is the last one, so 
> that's the one I stored in intel_uc_fw.file_selected (in the next 
> patch). The other 2  versions are not strictly required to use the GSC 
> and we only fetch them for debug purposes, so if something goes wrong we 
> know exactly what we've loaded.
> 
> Daniele
alan: okay thanks - seeing that now in the next patch... (and i also forgot that
the GSC release version doesnt reflect interface versioning in anyway like GuC 
does).
In that case, above additional versions are fine. Would definitely love to see
additional comments under "GSC-specific-additions" that explain those 3 
versioning
items and what we care about as how you have explained here.

Re: [Intel-gfx] [PATCH 4/6] drm/i915/uc/gsc: query the GSC FW for its compatibility version

[Teres Alexis, Alan Previn]

On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:
> The compatibility version is queried via an MKHI command. Right now, the
> only existing interface is 1.0
> This is basically the interface version for the GSC FW, so the plan is
> to use it as the main tracked version, including for the binary naming
> in the fetch code.
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> 

alan: just a couple of minor things nits below.
One ask though, in line with the clarification we had over the offline 
coversation,
I am wondering if we can document the fact that the file_selected.ver remains 
as major-minor::zero-zero
for the case of gsc until after the firmware is loaded and we query via this 
function (which happens
later at gt-late-init). However, that comment might not belong here - perhaps 
it belongs in the prior
patch together with the other comment i requested for (asking for additional 
explainations about the
different types of versions for gsc).

That said, for this patch, LGTM:
Reviewed-by: Alan Previn 

alan:snip
> +static int gsc_fw_query_compatibility_version(struct intel_gsc_uc *gsc)
> +{
> + struct intel_gt *gt = gsc_uc_to_gt(gsc);
> + struct mtl_gsc_ver_msg_in *msg_in;
> + struct mtl_gsc_ver_msg_out *msg_out;
> + struct i915_vma *vma;
> + u64 offset;
> + void *vaddr;
> + int err;
> +
> + err = intel_guc_allocate_and_map_vma(>->uc.guc, PAGE_SIZE * 2,
> +  &vma, &vaddr);
alan: nit: im assuming this code will be used for future discrete cards,.. if 
so,
perhaps we should also be using "SZ_4K * 2" above since different host-cpu-arch
could have different PAGE sizes - this way we'll be consistent with exact size 
allocations.
also its more consistent in this function - maybe a #define 
GSC_UC_GET_ABI_VER_PKT_SIZE SZ_4K
at top of function is nice. either way, i consider this a nit.

> + if (err) {
> + gt_err(gt, "failed to allocate vma for GSC version query\n");
> + return err;
> + }

alan:snip

> +
>  int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
>  {
>   struct intel_gt *gt = gsc_uc_to_gt(gsc);
> @@ -327,11 +406,21 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
>   if (err)
>   goto fail;
>  
> + err = gsc_fw_query_compatibility_version(gsc);
> + if (err)
> + goto fail;
> +
> + /* we only support compatibility version 1.0 at the moment */
> + err = intel_uc_check_file_version(gsc_fw, NULL);
> + if (err)
> + goto fail;
> +
>   /* FW is not fully operational until we enable SW proxy */
>   intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
>  
> - gt_info(gt, "Loaded GSC firmware %s (r%u.%u.%u.%u, svn%u)\n",
> + gt_info(gt, "Loaded GSC firmware %s (cv%u.%u, r%u.%u.%u.%u, svn %u)\n",
alan:nit "abi" instead of "cv"?
>   gsc_fw->file_selected.path,
> + gsc_fw->file_selected.ver.major, 
> gsc_fw->file_selected.ver.minor,
>   gsc->release.major, gsc->release.minor,
>   gsc->release.patch, gsc->release.build,
>   gsc->security_version);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> index 8f199d5f963e..fb1453ed4ecf 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
alan:snip

> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index cd8fc194f7fa..36ee96c02d74 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
alan:snip

> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
> index 279244744d43..4406e7b48b27 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
alan:snip

Re: [Intel-gfx] [PATCH v10 00/10] drm/hdcp: Pull HDCP auth/exchange/check into helpers

[Doug Anderson]

Mark,

On Mon, May 22, 2023 at 5:59 AM Rodrigo Vivi  wrote:
>
> On Sat, May 20, 2023 at 02:07:51AM +0300, Dmitry Baryshkov wrote:
> > On 20/05/2023 00:16, Rodrigo Vivi wrote:
> > > On Fri, May 19, 2023 at 07:55:47PM +0300, Dmitry Baryshkov wrote:
> > > > On 19/04/2023 18:43, Mark Yacoub wrote:
> > > > > Hi all,
> > > > > This is v10 of the HDCP patches. The patches are authored by Sean 
> > > > > Paul.
> > > > > I rebased and addressed the review comments in v6-v10.
> > > > >
> > > > > Main change in v10 is handling the kernel test bot warnings.
> > > > >
> > > > > Patches 1-4 focus on moving the common HDCP helpers to common DRM.
> > > > > This introduces a slight change in the original intel flow
> > > > > as it splits the unique driver protocol from the generic 
> > > > > implementation.
> > > > >
> > > > > Patches 5-7 split the HDCP flow on the i915 driver to make use of the 
> > > > > common DRM helpers.
> > > > >
> > > > > Patches 8-10 implement HDCP on MSM driver.
> > > > >
> > > > > Thanks,
> > > > > -Mark Yacoub
> > > > >
> > > > > Sean Paul (10):
> > > > > drm/hdcp: Add drm_hdcp_atomic_check()
> > > > > drm/hdcp: Avoid changing crtc state in hdcp atomic check
> > > > > drm/hdcp: Update property value on content type and user changes
> > > > > drm/hdcp: Expand HDCP helper library for enable/disable/check
> > > > > drm/i915/hdcp: Consolidate HDCP setup/state cache
> > > > > drm/i915/hdcp: Retain hdcp_capable return codes
> > > > > drm/i915/hdcp: Use HDCP helpers for i915
> > > > > dt-bindings: msm/dp: Add bindings for HDCP registers
> > > > > arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller
> > > >
> > > > Dear i915 maintainers,
> > > >
> > > > I wanted to ping you regarding this patch series. If there are no 
> > > > comments
> > > > for the series from you side, would it be possible to land 
> > > > Intel-specific
> > > > and generic patches into drm-intel tree? We will continue working on 
> > > > the msm
> > > > specific parts and merge them through the msm tree.
> > >
> > > pushed to drm-intel-next.
> > >
> > > should be propagated in a few weeks to drm-next on our next pull request.
> >
> > Probably there is some kind of confusion here. You've pushed the DSC
> > patches, while the response was sent to the HDCP series.
>
> I'm sorry, my confusion for replying to the wrong thread.
>
> So, on this one here I believe it would be helpful if there's a split
> in the series with the already reviewed ones related to i915 are resent
> separated from the rest, send with --subject-prefix="CI" so when that
> pass CI we just merge it through drm-intel-next

It sounds like this is waiting on you to post just the first 7 patches
with the proper subject prefix so they can land through the Intel
tree.

-Doug

Re: [Intel-gfx] [PATCH 5/6] drm/i915/uc/gsc: define gsc fw

[Teres Alexis, Alan Previn]

Considering the only request i have below is touching up of existing comments 
(as
far as this patch is concerned), and since the rest of the code looks good, 
here is
my R-b - but i hope you can anwser my newbie question at the bottom:

Reviewed-by: Alan Previn 

On Fri, 2023-05-05 at 09:04 -0700, Ceraolo Spurio, Daniele wrote:
> Add FW definition and the matching override modparam.
> 
> The GSC FW has both a release version, based on platform and a rolling
> counter, and a compatibility version, which is the one tracking
> interface changes. Since what we care about is the interface, we use
> the compatibility version in the buinary names.
alan :s/buinary/binary

> 
> Same as with the GuC, a major version bump indicate a
> backward-incompatible change, while a minor version bump indicates a
> backward-compatible one, so we use only the former in the file name.
> 
> Signed-off-by: Daniele Ceraolo Spurio 
> Cc: Alan Previn 
> Cc: John Harrison 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 32 ++--
>  1 file changed, 24 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index 36ee96c02d74..531cd172151d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -124,6 +124,18 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
>   fw_def(BROXTON,  0, huc_mmp(bxt,  2, 0, 0)) \
>   fw_def(SKYLAKE,  0, huc_mmp(skl,  2, 0, 0))
>  
> +/*
> + * The GSC FW has both a release version, based on platform and a rolling
> + * counter, and a compatibility version, which is the one tracking
> + * interface changes. Since what we care about is the interface, we use
> + * the compatibility version in the buinary names.
alan:s/buinary/binary
also, since we will (i hope) be adding several comments (alongside the new
version objects under intel_gsc_uc structure) in the patch #3 about what
their differences are and which one we care about and when they get populated,
perhaps we can minimize the information here and redirect to that other
comment... OR ... we can minimize the comments in patch #3 and redirect here
(will be good to have a single location with detailed explaination in the
comments and a redirect-ptr from the other location since a reader would
most likely stumble onto those questions from either of these locations).

> + * Same as with the GuC, a major version bump indicate a
> + * backward-incompatible change, while a minor version bump indicates a
> + * backward-compatible one, so we use only the former in the file name.
> + */
> +#define INTEL_GSC_FIRMWARE_DEFS(fw_def, gsc_def) \
> + fw_def(METEORLAKE,   0, gsc_def(mtl, 1, 0))
> +
>  /*
>  
> 
alan:snip

> @@ -257,14 +281,6 @@ __uc_fw_auto_select(struct drm_i915_private *i915, 
> struct intel_uc_fw *uc_fw)
>   int i;
>   bool found;
>  
> - /*
> -  * GSC FW support is still not fully in place, so we're not defining
> -  * the FW blob yet because we don't want the driver to attempt to load
> -  * it until we're ready for it.
> -  */
> - if (uc_fw->type == INTEL_UC_FW_TYPE_GSC)
> - return;
> -
alan: more of a newbie question from myself: considering this is a new firmware
we are adding, is there some kind of requirement to provide a link to the patch
targetting the linux firmware repo that is a dependency of this series?
or perhaps we should mention in the series that merge will only happen after
that patch gets merged (with a final rev that includes the patch on
the fw-repo side?). Just trying to understand the process.


>   /*
>* The only difference between the ADL GuC FWs is the HWConfig support.
>* ADL-N does not support HWConfig, so we should use the same binary as

Re: [Intel-gfx] [PATCH] drm/i915: use localized __diag_ignore_all() instead of per file

[Gustavo Sousa]

Quoting Jani Nikula (2023-05-25 18:06:53-03:00)
>Use localized __diag_push(), __diag_ignore_all() with rationale, and
>__diag_pop() for specific initializations instead of blanket disabling
>of -Woverride-init across several files.
>
>Signed-off-by: Jani Nikula 

Reviewed-by: Gustavo Sousa 

>---
> drivers/gpu/drm/i915/Makefile   | 5 -
> drivers/gpu/drm/i915/display/intel_display_device.c | 5 +
> drivers/gpu/drm/i915/display/intel_fbdev.c  | 5 +
> drivers/gpu/drm/i915/i915_pci.c | 5 +
> 4 files changed, 15 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>index 06374fc072d3..1c9ed4c52760 100644
>--- a/drivers/gpu/drm/i915/Makefile
>+++ b/drivers/gpu/drm/i915/Makefile
>@@ -23,11 +23,6 @@ subdir-ccflags-y += $(call cc-disable-warning, 
>unused-but-set-variable)
> subdir-ccflags-y += $(call cc-disable-warning, frame-address)
> subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
> 
>-# Fine grained warnings disable
>-CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
>-CFLAGS_display/intel_display_device.o = $(call cc-disable-warning, 
>override-init)
>-CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)
>-
> subdir-ccflags-y += -I$(srctree)/$(src)
> 
> # Please keep these build lists sorted!
>diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c 
>b/drivers/gpu/drm/i915/display/intel_display_device.c
>index a513ac8f71a3..464df1764a86 100644
>--- a/drivers/gpu/drm/i915/display/intel_display_device.c
>+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
>@@ -14,6 +14,9 @@
> #include "intel_display_reg_defs.h"
> #include "intel_fbc.h"
> 
>+__diag_push();
>+__diag_ignore_all("-Woverride-init", "Allow overriding inherited members");
>+
> static const struct intel_display_device_info no_display = {};
> 
> #define PIPE_A_OFFSET0x7
>@@ -650,6 +653,8 @@ static const struct intel_display_device_info 
>xe_lpdp_display = {
> BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> };
> 
>+__diag_pop();
>+
> #undef INTEL_VGA_DEVICE
> #undef INTEL_QUANTA_VGA_DEVICE
> #define INTEL_VGA_DEVICE(id, info) { id, info }
>diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
>b/drivers/gpu/drm/i915/display/intel_fbdev.c
>index aab1ae74a8f7..2c3f7befed17 100644
>--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
>+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
>@@ -130,6 +130,9 @@ static int intel_fbdev_mmap(struct fb_info *info, struct 
>vm_area_struct *vma)
> return i915_gem_fb_mmap(obj, vma);
> }
> 
>+__diag_push();
>+__diag_ignore_all("-Woverride-init", "Allow overriding the default ops");
>+
> static const struct fb_ops intelfb_ops = {
> .owner = THIS_MODULE,
> DRM_FB_HELPER_DEFAULT_OPS,
>@@ -144,6 +147,8 @@ static const struct fb_ops intelfb_ops = {
> .fb_mmap = intel_fbdev_mmap,
> };
> 
>+__diag_pop();
>+
> static int intelfb_alloc(struct drm_fb_helper *helper,
>  struct drm_fb_helper_surface_size *sizes)
> {
>diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
>index 928975d5fe2f..3d7a5db9833b 100644
>--- a/drivers/gpu/drm/i915/i915_pci.c
>+++ b/drivers/gpu/drm/i915/i915_pci.c
>@@ -38,6 +38,9 @@
> #include "i915_reg.h"
> #include "intel_pci_config.h"
> 
>+__diag_push();
>+__diag_ignore_all("-Woverride-init", "Allow overriding inherited members");
>+
> #define PLATFORM(x) .platform = (x)
> #define GEN(x) \
> .__runtime.graphics.ip.ver = (x), \
>@@ -843,6 +846,8 @@ static const struct intel_device_info mtl_info = {
> 
> #undef PLATFORM
> 
>+__diag_pop();
>+
> /*
>  * Make sure any device matches here are from most specific to most
>  * general.  For example, since the Quanta match is based on the subsystem
>-- 
>2.39.2
>

[Intel-gfx] ✗ Fi.CI.IGT: failure for Expose RPS thresholds in sysfs (rev3)

[Patchwork]

== Series Details ==

Series: Expose RPS thresholds in sysfs (rev3)
URL   : https://patchwork.freedesktop.org/series/117054/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_117054v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@api_intel_allocator@execbuf-with-allocator:
- shard-glk:  [PASS][1] -> [TIMEOUT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk6/igt@api_intel_alloca...@execbuf-with-allocator.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/shard-glk6/igt@api_intel_alloca...@execbuf-with-allocator.html

  
 Warnings 

  * igt@gen3_render_tiledx_blits:
- shard-glk:  [SKIP][3] ([fdo#109271]) -> [TIMEOUT][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk1/igt@gen3_render_tiledx_blits.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/shard-glk6/igt@gen3_render_tiledx_blits.html

  
New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_117054v3_full:

### New IGT tests (15) ###

  * igt@i915_pm_rps@thresholds:
- Statuses :
- Exec time: [None] s

  * igt@i915_pm_rps@thresholds-idle:
- Statuses :
- Exec time: [None] s

  * igt@i915_pm_rps@thresholds-idle-park:
- Statuses :
- Exec time: [None] s

  * igt@i915_pm_rps@thresholds-idle-park@gt0:
- Statuses : 4 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@i915_pm_rps@thresholds-idle@gt0:
- Statuses : 4 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@i915_pm_rps@thresholds-park:
- Statuses :
- Exec time: [None] s

  * igt@i915_pm_rps@thresholds-park@gt0:
- Statuses : 4 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@i915_pm_rps@thresholds@gt0:
- Statuses : 5 pass(s) 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_barrier_race@remote-request@rcs0:
- shard-glk:  [PASS][5] -> [ABORT][6] ([i915#7461] / [i915#8211])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk8/igt@gem_barrier_race@remote-requ...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/shard-glk8/igt@gem_barrier_race@remote-requ...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][7] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@basic:
- shard-glk:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/shard-glk8/igt@gem_lmem_swapp...@basic.html

  * igt@gen9_exec_parse@allowed-single:
- shard-apl:  [PASS][9] -> [ABORT][10] ([i915#5566])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-apl2/igt@gen9_exec_pa...@allowed-single.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/shard-apl7/igt@gen9_exec_pa...@allowed-single.html

  * {igt@i915_pm_rps@thresholds-idle@gt0} (NEW):
- {shard-dg1}:NOTRUN -> [SKIP][11] ([i915#4579]) +3 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117054v3/shard-dg1-17/igt@i915_pm_rps@thresholds-i...@gt0.html

  * ig

Re: [Intel-gfx] [PATCH v6 09/10] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev

[Baolu Lu]

On 5/25/23 9:02 PM, Liu, Yi L wrote:

  It's possible that requirement
might be relaxed in the new DMA ownership model, but as it is right
now, the code enforces that requirement and any new discussion about
what makes hot-reset available should note both the ownership and
dev_set requirement.  Thanks,

I think your point is that if an iommufd_ctx has acquired DMA ownerhisp
of an iommu_group, it means the device is owned. And it should not
matter whether all the devices in the iommu_group is present in the
dev_set. It is allowed that some devices are bound to pci-stub or
pcieport driver. Is it?

Actually I have a doubt on it. IIUC, the above requirement on dev_set
is to ensure the reset to the devices are protected by the dev_set->lock.
So that either the reset issued by driver itself or a hot reset request
from user, there is no race. But if a device is not in the dev_set, then
hot reset request from user might race with the bound driver. DMA ownership
only guarantees the drivers won't handle DMA via DMA API which would have
conflict with DMA mappings from user. I'm not sure if it is able to
guarantee reset is exclusive as well. I see pci-stub and pcieport driver
are the only two drivers that set the driver_managed_dma flag besides the
vfio drivers. pci-stub may be fine. not sure about pcieport driver.


commit c7d469849747 ("PCI: portdrv: Set driver_managed_dma") described
the criteria of adding driver_managed_dma to the pcieport driver.

"
We achieve this by setting ".driver_managed_dma = true" in pci_driver
structure. It is safe because the portdrv driver meets below criteria:

- This driver doesn't use DMA, as you can't find any related calls like
  pci_set_master() or any kernel DMA API (dma_map_*() and etc.).
- It doesn't use MMIO as you can't find ioremap() or similar calls. It's
  tolerant to userspace possibly also touching the same MMIO registers
  via P2P DMA access.
"

pci_rest_device() definitely shouldn't be done by the kernel drivers
that have driver_managed_dma set.



#   line  filename / context / line
1 39  drivers/pci/pci-stub.c <>
  .driver_managed_dma = true,
2796  drivers/pci/pcie/portdrv.c <>
  .driver_managed_dma = true,
3607  drivers/vfio/fsl-mc/vfio_fsl_mc.c <>
  .driver_managed_dma = true,
4   1459  drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c <>
  .driver_managed_dma = true,
5   1374  drivers/vfio/pci/mlx5/main.c <>
  .driver_managed_dma = true,
6203  drivers/vfio/pci/vfio_pci.c <>
  .driver_managed_dma = true,
7139  drivers/vfio/platform/vfio_amba.c <>
  .driver_managed_dma = true,
8120  drivers/vfio/platform/vfio_platform.c <>
  .driver_managed_dma = true,

Anyhow, I think this is not a must so far. is it? Even doable, it shall
be done in the future. 😄


Perhaps we can take it in this way: it's a bug if any driver sets its
driver_managed_dma but still resets the hardware during it's life cycle?

Best regards,
baolu

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gsc: use system include style for drm headers

[Patchwork]

== Series Details ==

Series: drm/i915/gsc: use system include style for drm headers
URL   : https://patchwork.freedesktop.org/series/118359/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_118359v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_118359v1_full:

### New IGT tests (7) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][1] ([i915#2842])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-glk4/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@basic:
- shard-glk:  NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-glk4/igt@gem_lmem_swapp...@basic.html

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][3] -> [ABORT][4] ([i915#5566])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk9/igt@gen9_exec_pa...@allowed-all.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-glk2/igt@gen9_exec_pa...@allowed-all.html

  * igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-glk4/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs:
- shard-glk:  NOTRUN -> [SKIP][6] ([fdo#109271]) +15 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-glk4/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs.html

  * igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#79])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu:
- shard-glk:  NOTRUN -> [SKIP][9] ([IGT#6] / [fdo#109271]) +10 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-glk4/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-20x20@pipe-b-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4579]) +9 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-snb1/igt@kms_plane_scaling@plane-upscale-with-modifiers-20...@pipe-b-hdmi-a-1.html

  * 
igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0-25@pipe-a-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][11] ([fdo#109271]) +11 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-snb1/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0...@pipe-a-hdmi-a-1.html

  * igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-c-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4579]) +2 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118359v1/shard-glk4/igt@kms_plane_scaling@planes-downscale-factor-0...@pipe-c-hdmi-a-1.html

  
 Possible fixes 

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [FAIL][13] ([i915#2846]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk6/igt@gem_exec_f...@basic-deadline.html
   [14]: 
https://intel-gfx-ci.01.org/tre

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix the disabling sequence for Bigjoiner

[Patchwork]

== Series Details ==

Series: drm/i915: Fix the disabling sequence for Bigjoiner
URL   : https://patchwork.freedesktop.org/series/118360/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_118360v1_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (7 -> 7)
--

  No changes in participating hosts

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@gem_ctx_shared@create-shared-gtt:
- {shard-rkl}:[PASS][1] -> [ABORT][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-rkl-4/igt@gem_ctx_sha...@create-shared-gtt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/shard-rkl-4/igt@gem_ctx_sha...@create-shared-gtt.html

  
New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_118360v1_full:

### New IGT tests (8) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * 
igt@kms_plane_scaling@plane-downscale-with-modifiers-factor-0-75@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_psr2_sf:
- Statuses :
- Exec time: [None] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl:  [PASS][3] -> [FAIL][4] ([i915#2842])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-apl2/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-apl:  [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-apl2/igt@i915_selftest@live@gt_heartbeat.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/shard-apl7/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-20x20@pipe-b-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4579]) +9 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/shard-snb1/igt@kms_plane_scaling@plane-upscale-with-modifiers-20...@pipe-b-hdmi-a-1.html

  * 
igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-a-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271]) +12 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/shard-snb1/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0...@pipe-a-hdmi-a-1.html

  * igt@perf@stress-open-close@0-rcs0:
- shard-glk:  [PASS][9] -> [ABORT][10] ([i915#5213] / [i915#7941])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk7/igt@perf@stress-open-cl...@0-rcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/shard-glk4/igt@perf@stress-open-cl...@0-rcs0.html

  
 Possible fixes 

  * igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-rkl-6/igt@drm_fdinfo@most-busy-check-...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/shard-rkl-6/igt@drm_fdinfo@most-busy-check-...@rcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-glk:  [FAIL][13] ([i915#2846]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-glk6/igt@gem_exec_f...@basic-deadline.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118360v1/shard-glk5/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vecs0:
- {shard-rkl}:[FAIL][15] ([i915#2842]) -> [PASS][16] +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-rkl-1/igt@gem_exec_fair@basic-n...@vecs0.h

Re: [Intel-gfx] [PATCH v3 00/22] drm/i915: Init DDI ports in VBT order

[Kai-Heng Feng]

On Wed, Feb 22, 2023 at 7:02 AM Ville Syrjala
 wrote:
>
> From: Ville Syrjälä 
>
> I just wanted to init DDI ports in VBT child device order
> without any up front assumptions about which conflicting
> child device defition is valid. That is pretty much what
> we need to do for the ADL laptops with the phantom eDP vs.
> native HDMI on DDI B.
>
> However that approach doesn't work for some of the weird
> SKL boards that have a phantom eDP on DDI A+AUX A and
> and a real DP->VGA converter on DDI E+AUX A. For those
> I had to introduce HPD live status check during eDP init.
>
> One of the remaining concerns I still have is what happens
> when we encounter VBTs with more AUX CH/DDC pin conflicts?
> I think what we might want to do eventually is ignore the
> conflicts as much as possible, and just init everything
> based on VBT, trusting HPD to take care of things in the
> end. That of course does have certain issues wrt. connector
> forcing, but dunno if we can avoid those at all.
>
> Also I think we need to nuke all the platform default AUX
> CH/DDC pin stuff, or at least only try to utilize those
> only once we've consumed the VBT fully.
>
> v2: Fix SKL DDI A HPD live state
> v3: Replace AUX CH/DDC pin sanitation with availability checks

The series can solve HDMI detection issue on an ADL laptop.
The caveat is that it can't be cleanly applied to current drm-tip, so
the test was conducted on older drm tag.

Tested-by: Kai-Heng Feng 

> Ville Syrjälä (22):
>   drm/i915: Populate dig_port->connected() before connector init
>   drm/i915: Fix SKL DDI A digital port .connected()
>   drm/i915: Get rid of the gm45 HPD live state nonsense
>   drm/i915: Introduce _hotplug_mask()
>   drm/i915: Introduce intel_hpd_detection()
>   drm/i915: Check HPD live state during eDP probe
>   drm/i915: Sanitize child devices later
>   drm/i915: Split map_aux_ch() into per-platform arrays
>   drm/i915: Flip VBT DDC pin maps around
>   drm/i915: Nuke intel_bios_is_port_dp_dual_mode()
>   drm/i915: Remove bogus DDI-F from hsw/bdw output init
>   drm/i915: Introduce device info port_mask
>   drm/i915: Assert that device info bitmasks have enough bits
>   drm/i915: Assert that the port being initialized is valid
>   drm/i915: Beef up SDVO/HDMI port checks
>   drm/i915: Init DDI outputs based on port_mask on skl+
>   drm/i915: Try to initialize DDI/ICL+ DSI ports for every VBT child
> device
>   drm/i915: Convert HSW/BDW to use VBT driven DDI probe
>   drm/i915: Remove DDC pin sanitation
>   drm/i915: Remove AUX CH sanitation
>   drm/i915: Initialize dig_port->aux_ch to NONE to be sure
>   drm/i915: Only populate aux_ch is really needed
>
>  drivers/gpu/drm/i915/display/g4x_dp.c |  39 +-
>  drivers/gpu/drm/i915/display/g4x_hdmi.c   |  26 +-
>  drivers/gpu/drm/i915/display/icl_dsi.c|  11 +-
>  drivers/gpu/drm/i915/display/icl_dsi.h|   6 +-
>  drivers/gpu/drm/i915/display/intel_bios.c | 422 +++---
>  drivers/gpu/drm/i915/display/intel_bios.h |  12 +-
>  drivers/gpu/drm/i915/display/intel_crt.c  |   2 +
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 148 --
>  drivers/gpu/drm/i915/display/intel_ddi.h  |   5 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  89 +---
>  drivers/gpu/drm/i915/display/intel_display.h  |   2 +
>  .../gpu/drm/i915/display/intel_display_core.h |   2 -
>  drivers/gpu/drm/i915/display/intel_dp.c   |  28 ++
>  drivers/gpu/drm/i915/display/intel_dp_aux.c   |  51 ++-
>  drivers/gpu/drm/i915/display/intel_dvo.c  |   2 +
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  78 +++-
>  drivers/gpu/drm/i915/display/intel_sdvo.c |  20 +-
>  drivers/gpu/drm/i915/i915_irq.c   | 365 ---
>  drivers/gpu/drm/i915/i915_irq.h   |   2 +
>  drivers/gpu/drm/i915/i915_pci.c   |  31 ++
>  drivers/gpu/drm/i915/i915_reg.h   |  13 +-
>  drivers/gpu/drm/i915/intel_device_info.c  |   9 +
>  drivers/gpu/drm/i915/intel_device_info.h  |   1 +
>  23 files changed, 843 insertions(+), 521 deletions(-)
>
> --
> 2.39.2
>
>

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add rc_range_params for YUV420 (rev3)

[Patchwork]

== Series Details ==

Series: Add rc_range_params for YUV420 (rev3)
URL   : https://patchwork.freedesktop.org/series/118204/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_13187_full -> Patchwork_118204v3_full


Summary
---

  **FAILURE**

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

  

Participating hosts (7 -> 8)
--

  Additional (1): shard-rkl0 

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_invalid_mode@bad-htotal:
- shard-snb:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-snb1/igt@kms_invalid_m...@bad-htotal.html

  
New tests
-

  New tests have been introduced between CI_DRM_13187_full and 
Patchwork_118204v3_full:

### New IGT tests (5) ###

  * igt@kms_flip@2x-dpms-vs-vblank-race@ab-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@ac-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2:
- Statuses : 1 pass(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  * igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-vga-1:
- Statuses : 1 skip(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl:  [PASS][2] -> [FAIL][3] ([i915#2842])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-apl4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-apl3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][4] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_lmem_swapping@basic:
- shard-glk:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-glk5/igt@gem_lmem_swapp...@basic.html

  * igt@i915_selftest@live@gt_heartbeat:
- shard-apl:  [PASS][6] -> [DMESG-FAIL][7] ([i915#5334])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-apl2/igt@i915_selftest@live@gt_heartbeat.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-apl7/igt@i915_selftest@live@gt_heartbeat.html

  * igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886]) +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-glk5/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html

  * igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs:
- shard-glk:  NOTRUN -> [SKIP][9] ([fdo#109271]) +15 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-glk5/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs.html

  * igt@kms_color@degamma@pipe-b-hdmi-a-1:
- shard-snb:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4579]) +12 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-snb1/igt@kms_color@dega...@pipe-b-hdmi-a-1.html

  * igt@kms_flip@flip-vs-expired-vblank@b-dp1:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#79])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13187/shard-apl4/igt@kms_flip@flip-vs-expired-vbl...@b-dp1.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-apl3/igt@kms_flip@flip-vs-expired-vbl...@b-dp1.html

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-cpu:
- shard-glk:  NOTRUN -> [SKIP][13] ([IGT#6] / [fdo#109271]) +10 
similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-glk5/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-cpu.html

  * igt@kms_plane_scaling@planes-downscale-factor-0-25@pipe-c-hdmi-a-1:
- shard-glk:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4579]) +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_118204v3/shard-glk5/igt@kms_plane_sca