* [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state
@ 2023-10-24 12:52 Stanislav Lisovskiy
2023-10-24 13:04 ` Jani Nikula
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: Stanislav Lisovskiy @ 2023-10-24 12:52 UTC (permalink / raw)
To: intel-gfx
In some customer cases, machine can start up with all
GV points restricted. However we don't ever read those
from hw and initial driver qgv_points_mask is initialized
as 0, which would make driver think that all points are unrestricted,
so we never update them with proper value, unless
some demanding scenario is requested or we have to toggle SAGV
and we have to restrict some of those.
Lets fix that by initializing all points as restricted,
then on first modeset, that will make sure driver will naturally
calculate, which of those need to be relaxed and do correspondent update.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
---
drivers/gpu/drm/i915/display/intel_bw.c | 7 ++++---
drivers/gpu/drm/i915/display/intel_bw.h | 1 +
drivers/gpu/drm/i915/display/intel_modeset_setup.c | 13 +++++++++++++
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c
index bef96db62c80..fbfa01f38db8 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -119,7 +119,7 @@ static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv,
return 0;
}
-static u16 icl_qgv_points_mask(struct drm_i915_private *i915)
+u16 icl_qgv_points_mask(struct drm_i915_private *i915)
{
unsigned int num_psf_gv_points = i915->display.bw.max[0].num_psf_gv_points;
unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points;
@@ -1277,9 +1277,10 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
/*
* If none of our inputs (data rates, number of active
- * planes, SAGV yes/no) changed then nothing to do here.
+ * planes, SAGV yes/no) changed then nothing to do here,
+ * except if mask turns out to be in wrong state initially.
*/
- if (!changed)
+ if (!changed && (new_bw_state->qgv_points_mask != icl_qgv_points_mask(i915)))
return 0;
ret = intel_bw_check_qgv_points(i915, old_bw_state, new_bw_state);
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h
index 59cb4fc5db76..0a706ec79ce3 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -70,6 +70,7 @@ void intel_bw_crtc_update(struct intel_bw_state *bw_state,
const struct intel_crtc_state *crtc_state);
int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
u32 points_mask);
+u16 icl_qgv_points_mask(struct drm_i915_private *i915);
int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
bool *need_cdclk_calc);
int intel_bw_min_cdclk(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
index b8f43efb0ab5..230090c6e994 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
@@ -871,6 +871,19 @@ static void intel_modeset_readout_hw_state(struct drm_i915_private *i915)
intel_pmdemand_update_port_clock(i915, pmdemand_state, pipe,
crtc_state->port_clock);
+ /*
+ * In some customer cases, machine can start up with all
+ * GV points restricted. However we don't ever read those
+ * from hw and qgv_points_mask initialized as 0, would
+ * make driver think that all points are unrestricted,
+ * so we never update them with proper value, unless
+ * some demanding scenario is requested and we have to
+ * restrict some of those. Lets fix that by initializing
+ * all points as restricted, then on first modeset, driver
+ * will naturally calculate, which of those need to be
+ * relaxed and do correspondent update.
+ */
+ bw_state->qgv_points_mask = icl_qgv_points_mask(i915);
intel_bw_crtc_update(bw_state, crtc_state);
}
--
2.37.3
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state 2023-10-24 12:52 [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state Stanislav Lisovskiy @ 2023-10-24 13:04 ` Jani Nikula 2023-10-24 14:01 ` Ville Syrjälä ` (2 subsequent siblings) 3 siblings, 0 replies; 6+ messages in thread From: Jani Nikula @ 2023-10-24 13:04 UTC (permalink / raw) To: Stanislav Lisovskiy, intel-gfx On Tue, 24 Oct 2023, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> wrote: > In some customer cases, machine can start up with all > GV points restricted. However we don't ever read those > from hw and initial driver qgv_points_mask is initialized > as 0, which would make driver think that all points are unrestricted, > so we never update them with proper value, unless > some demanding scenario is requested or we have to toggle SAGV > and we have to restrict some of those. > Lets fix that by initializing all points as restricted, > then on first modeset, that will make sure driver will naturally > calculate, which of those need to be relaxed and do correspondent update. > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> > --- > drivers/gpu/drm/i915/display/intel_bw.c | 7 ++++--- > drivers/gpu/drm/i915/display/intel_bw.h | 1 + > drivers/gpu/drm/i915/display/intel_modeset_setup.c | 13 +++++++++++++ > 3 files changed, 18 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c > index bef96db62c80..fbfa01f38db8 100644 > --- a/drivers/gpu/drm/i915/display/intel_bw.c > +++ b/drivers/gpu/drm/i915/display/intel_bw.c > @@ -119,7 +119,7 @@ static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv, > return 0; > } > > -static u16 icl_qgv_points_mask(struct drm_i915_private *i915) > +u16 icl_qgv_points_mask(struct drm_i915_private *i915) > { > unsigned int num_psf_gv_points = i915->display.bw.max[0].num_psf_gv_points; > unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points; > @@ -1277,9 +1277,10 @@ int intel_bw_atomic_check(struct intel_atomic_state *state) > > /* > * If none of our inputs (data rates, number of active > - * planes, SAGV yes/no) changed then nothing to do here. > + * planes, SAGV yes/no) changed then nothing to do here, > + * except if mask turns out to be in wrong state initially. > */ > - if (!changed) > + if (!changed && (new_bw_state->qgv_points_mask != icl_qgv_points_mask(i915))) > return 0; > > ret = intel_bw_check_qgv_points(i915, old_bw_state, new_bw_state); > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h > index 59cb4fc5db76..0a706ec79ce3 100644 > --- a/drivers/gpu/drm/i915/display/intel_bw.h > +++ b/drivers/gpu/drm/i915/display/intel_bw.h > @@ -70,6 +70,7 @@ void intel_bw_crtc_update(struct intel_bw_state *bw_state, > const struct intel_crtc_state *crtc_state); > int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv, > u32 points_mask); > +u16 icl_qgv_points_mask(struct drm_i915_private *i915); > int intel_bw_calc_min_cdclk(struct intel_atomic_state *state, > bool *need_cdclk_calc); > int intel_bw_min_cdclk(struct drm_i915_private *i915, > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c b/drivers/gpu/drm/i915/display/intel_modeset_setup.c > index b8f43efb0ab5..230090c6e994 100644 > --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c > +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c > @@ -871,6 +871,19 @@ static void intel_modeset_readout_hw_state(struct drm_i915_private *i915) > intel_pmdemand_update_port_clock(i915, pmdemand_state, pipe, > crtc_state->port_clock); > > + /* > + * In some customer cases, machine can start up with all > + * GV points restricted. However we don't ever read those > + * from hw and qgv_points_mask initialized as 0, would > + * make driver think that all points are unrestricted, > + * so we never update them with proper value, unless > + * some demanding scenario is requested and we have to > + * restrict some of those. Lets fix that by initializing > + * all points as restricted, then on first modeset, driver > + * will naturally calculate, which of those need to be > + * relaxed and do correspondent update. > + */ > + bw_state->qgv_points_mask = icl_qgv_points_mask(i915); Sad trombone for having to expose highly specific functions and stuff from intel_bw.c. Can't the below call handle it? BR, Jani. > intel_bw_crtc_update(bw_state, crtc_state); > } -- Jani Nikula, Intel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state 2023-10-24 12:52 [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state Stanislav Lisovskiy 2023-10-24 13:04 ` Jani Nikula @ 2023-10-24 14:01 ` Ville Syrjälä 2023-10-24 14:50 ` Lisovskiy, Stanislav 2023-10-25 0:26 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork 2023-10-25 0:42 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork 3 siblings, 1 reply; 6+ messages in thread From: Ville Syrjälä @ 2023-10-24 14:01 UTC (permalink / raw) To: Stanislav Lisovskiy; +Cc: intel-gfx On Tue, Oct 24, 2023 at 03:52:56PM +0300, Stanislav Lisovskiy wrote: > In some customer cases, machine can start up with all > GV points restricted. However we don't ever read those > from hw and initial driver qgv_points_mask is initialized > as 0, which would make driver think that all points are unrestricted, > so we never update them with proper value, unless > some demanding scenario is requested or we have to toggle SAGV > and we have to restrict some of those. > Lets fix that by initializing all points as restricted, > then on first modeset, that will make sure driver will naturally > calculate, which of those need to be relaxed and do correspondent update. > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> > --- > drivers/gpu/drm/i915/display/intel_bw.c | 7 ++++--- > drivers/gpu/drm/i915/display/intel_bw.h | 1 + > drivers/gpu/drm/i915/display/intel_modeset_setup.c | 13 +++++++++++++ > 3 files changed, 18 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c > index bef96db62c80..fbfa01f38db8 100644 > --- a/drivers/gpu/drm/i915/display/intel_bw.c > +++ b/drivers/gpu/drm/i915/display/intel_bw.c > @@ -119,7 +119,7 @@ static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv, > return 0; > } > > -static u16 icl_qgv_points_mask(struct drm_i915_private *i915) > +u16 icl_qgv_points_mask(struct drm_i915_private *i915) > { > unsigned int num_psf_gv_points = i915->display.bw.max[0].num_psf_gv_points; > unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points; > @@ -1277,9 +1277,10 @@ int intel_bw_atomic_check(struct intel_atomic_state *state) > > /* > * If none of our inputs (data rates, number of active > - * planes, SAGV yes/no) changed then nothing to do here. > + * planes, SAGV yes/no) changed then nothing to do here, > + * except if mask turns out to be in wrong state initially. > */ > - if (!changed) > + if (!changed && (new_bw_state->qgv_points_mask != icl_qgv_points_mask(i915))) There doesn't seem to be any guarantee that the bw state is actually present here. So this could oops. But I'm thinking a better fix might be to do what we on older platforms and just force SAGV off at the start. That way we actually know what state the hardware will be in. > return 0; > > ret = intel_bw_check_qgv_points(i915, old_bw_state, new_bw_state); > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h > index 59cb4fc5db76..0a706ec79ce3 100644 > --- a/drivers/gpu/drm/i915/display/intel_bw.h > +++ b/drivers/gpu/drm/i915/display/intel_bw.h > @@ -70,6 +70,7 @@ void intel_bw_crtc_update(struct intel_bw_state *bw_state, > const struct intel_crtc_state *crtc_state); > int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv, > u32 points_mask); > +u16 icl_qgv_points_mask(struct drm_i915_private *i915); > int intel_bw_calc_min_cdclk(struct intel_atomic_state *state, > bool *need_cdclk_calc); > int intel_bw_min_cdclk(struct drm_i915_private *i915, > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c b/drivers/gpu/drm/i915/display/intel_modeset_setup.c > index b8f43efb0ab5..230090c6e994 100644 > --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c > +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c > @@ -871,6 +871,19 @@ static void intel_modeset_readout_hw_state(struct drm_i915_private *i915) > intel_pmdemand_update_port_clock(i915, pmdemand_state, pipe, > crtc_state->port_clock); > > + /* > + * In some customer cases, machine can start up with all > + * GV points restricted. However we don't ever read those > + * from hw and qgv_points_mask initialized as 0, would > + * make driver think that all points are unrestricted, > + * so we never update them with proper value, unless > + * some demanding scenario is requested and we have to > + * restrict some of those. Lets fix that by initializing > + * all points as restricted, then on first modeset, driver > + * will naturally calculate, which of those need to be > + * relaxed and do correspondent update. > + */ > + bw_state->qgv_points_mask = icl_qgv_points_mask(i915); > intel_bw_crtc_update(bw_state, crtc_state); > } > > -- > 2.37.3 -- Ville Syrjälä Intel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state 2023-10-24 14:01 ` Ville Syrjälä @ 2023-10-24 14:50 ` Lisovskiy, Stanislav 0 siblings, 0 replies; 6+ messages in thread From: Lisovskiy, Stanislav @ 2023-10-24 14:50 UTC (permalink / raw) To: Ville Syrjälä; +Cc: intel-gfx On Tue, Oct 24, 2023 at 05:01:22PM +0300, Ville Syrjälä wrote: > On Tue, Oct 24, 2023 at 03:52:56PM +0300, Stanislav Lisovskiy wrote: > > In some customer cases, machine can start up with all > > GV points restricted. However we don't ever read those > > from hw and initial driver qgv_points_mask is initialized > > as 0, which would make driver think that all points are unrestricted, > > so we never update them with proper value, unless > > some demanding scenario is requested or we have to toggle SAGV > > and we have to restrict some of those. > > Lets fix that by initializing all points as restricted, > > then on first modeset, that will make sure driver will naturally > > calculate, which of those need to be relaxed and do correspondent update. > > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> > > --- > > drivers/gpu/drm/i915/display/intel_bw.c | 7 ++++--- > > drivers/gpu/drm/i915/display/intel_bw.h | 1 + > > drivers/gpu/drm/i915/display/intel_modeset_setup.c | 13 +++++++++++++ > > 3 files changed, 18 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/display/intel_bw.c > > index bef96db62c80..fbfa01f38db8 100644 > > --- a/drivers/gpu/drm/i915/display/intel_bw.c > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c > > @@ -119,7 +119,7 @@ static int adls_pcode_read_psf_gv_point_info(struct drm_i915_private *dev_priv, > > return 0; > > } > > > > -static u16 icl_qgv_points_mask(struct drm_i915_private *i915) > > +u16 icl_qgv_points_mask(struct drm_i915_private *i915) > > { > > unsigned int num_psf_gv_points = i915->display.bw.max[0].num_psf_gv_points; > > unsigned int num_qgv_points = i915->display.bw.max[0].num_qgv_points; > > @@ -1277,9 +1277,10 @@ int intel_bw_atomic_check(struct intel_atomic_state *state) > > > > /* > > * If none of our inputs (data rates, number of active > > - * planes, SAGV yes/no) changed then nothing to do here. > > + * planes, SAGV yes/no) changed then nothing to do here, > > + * except if mask turns out to be in wrong state initially. > > */ > > - if (!changed) > > + if (!changed && (new_bw_state->qgv_points_mask != icl_qgv_points_mask(i915))) > > There doesn't seem to be any guarantee that the bw state is > actually present here. So this could oops. > > But I'm thinking a better fix might be to do what we on > older platforms and just force SAGV off at the start. That > way we actually know what state the hardware will be in. If you mean that by forcing SAGV off, we will also update QGV point mask, leaving only the highest enabled, then yeah that could be better solution. Thing is that, as we can't read QGV point mask directly from HW, it is better to always update it initially, to avoid that kind of issues. Stan > > > return 0; > > > > ret = intel_bw_check_qgv_points(i915, old_bw_state, new_bw_state); > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h b/drivers/gpu/drm/i915/display/intel_bw.h > > index 59cb4fc5db76..0a706ec79ce3 100644 > > --- a/drivers/gpu/drm/i915/display/intel_bw.h > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h > > @@ -70,6 +70,7 @@ void intel_bw_crtc_update(struct intel_bw_state *bw_state, > > const struct intel_crtc_state *crtc_state); > > int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv, > > u32 points_mask); > > +u16 icl_qgv_points_mask(struct drm_i915_private *i915); > > int intel_bw_calc_min_cdclk(struct intel_atomic_state *state, > > bool *need_cdclk_calc); > > int intel_bw_min_cdclk(struct drm_i915_private *i915, > > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c b/drivers/gpu/drm/i915/display/intel_modeset_setup.c > > index b8f43efb0ab5..230090c6e994 100644 > > --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c > > +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c > > @@ -871,6 +871,19 @@ static void intel_modeset_readout_hw_state(struct drm_i915_private *i915) > > intel_pmdemand_update_port_clock(i915, pmdemand_state, pipe, > > crtc_state->port_clock); > > > > + /* > > + * In some customer cases, machine can start up with all > > + * GV points restricted. However we don't ever read those > > + * from hw and qgv_points_mask initialized as 0, would > > + * make driver think that all points are unrestricted, > > + * so we never update them with proper value, unless > > + * some demanding scenario is requested and we have to > > + * restrict some of those. Lets fix that by initializing > > + * all points as restricted, then on first modeset, driver > > + * will naturally calculate, which of those need to be > > + * relaxed and do correspondent update. > > + */ > > + bw_state->qgv_points_mask = icl_qgv_points_mask(i915); > > intel_bw_crtc_update(bw_state, crtc_state); > > } > > > > -- > > 2.37.3 > > -- > Ville Syrjälä > Intel ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adl: Initialize all GV points as restricted in bw_state 2023-10-24 12:52 [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state Stanislav Lisovskiy 2023-10-24 13:04 ` Jani Nikula 2023-10-24 14:01 ` Ville Syrjälä @ 2023-10-25 0:26 ` Patchwork 2023-10-25 0:42 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork 3 siblings, 0 replies; 6+ messages in thread From: Patchwork @ 2023-10-25 0:26 UTC (permalink / raw) To: Lisovskiy, Stanislav; +Cc: intel-gfx == Series Details == Series: drm/i915/adl: Initialize all GV points as restricted in bw_state URL : https://patchwork.freedesktop.org/series/125508/ State : warning == Summary == Error: dim checkpatch failed ac9117934e04 drm/i915/adl: Initialize all GV points as restricted in bw_state -:42: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'new_bw_state->qgv_points_mask != icl_qgv_points_mask(i915)' #42: FILE: drivers/gpu/drm/i915/display/intel_bw.c:1283: + if (!changed && (new_bw_state->qgv_points_mask != icl_qgv_points_mask(i915))) total: 0 errors, 0 warnings, 1 checks, 46 lines checked ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/adl: Initialize all GV points as restricted in bw_state 2023-10-24 12:52 [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state Stanislav Lisovskiy ` (2 preceding siblings ...) 2023-10-25 0:26 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork @ 2023-10-25 0:42 ` Patchwork 3 siblings, 0 replies; 6+ messages in thread From: Patchwork @ 2023-10-25 0:42 UTC (permalink / raw) To: Lisovskiy, Stanislav; +Cc: intel-gfx [-- Attachment #1: Type: text/plain, Size: 7450 bytes --] == Series Details == Series: drm/i915/adl: Initialize all GV points as restricted in bw_state URL : https://patchwork.freedesktop.org/series/125508/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13782 -> Patchwork_125508v1 ==================================================== Summary ------- **FAILURE** Serious unknown changes coming with Patchwork_125508v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125508v1, please notify your bug team (lgci.bug.filing@intel.com) to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/index.html Participating hosts (38 -> 35) ------------------------------ Missing (3): bat-mtlp-8 bat-adlp-11 fi-snb-2520m Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_125508v1: ### IGT changes ### #### Possible regressions #### * igt@kms_busy@basic@flip: - bat-adln-1: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-adln-1/igt@kms_busy@basic@flip.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-adln-1/igt@kms_busy@basic@flip.html - bat-rplp-1: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-rplp-1/igt@kms_busy@basic@flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-rplp-1/igt@kms_busy@basic@flip.html - fi-tgl-1115g4: [PASS][5] -> [ABORT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/fi-tgl-1115g4/igt@kms_busy@basic@flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/fi-tgl-1115g4/igt@kms_busy@basic@flip.html - bat-dg2-9: [PASS][7] -> [ABORT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-dg2-9/igt@kms_busy@basic@flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-dg2-9/igt@kms_busy@basic@flip.html - bat-jsl-1: [PASS][9] -> [ABORT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-jsl-1/igt@kms_busy@basic@flip.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-jsl-1/igt@kms_busy@basic@flip.html - bat-adlp-6: [PASS][11] -> [ABORT][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-adlp-6/igt@kms_busy@basic@flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-adlp-6/igt@kms_busy@basic@flip.html - fi-rkl-11600: [PASS][13] -> [ABORT][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/fi-rkl-11600/igt@kms_busy@basic@flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/fi-rkl-11600/igt@kms_busy@basic@flip.html - bat-jsl-3: [PASS][15] -> [ABORT][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-jsl-3/igt@kms_busy@basic@flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-jsl-3/igt@kms_busy@basic@flip.html - bat-adlp-9: [PASS][17] -> [ABORT][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-adlp-9/igt@kms_busy@basic@flip.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-adlp-9/igt@kms_busy@basic@flip.html - bat-dg2-11: [PASS][19] -> [ABORT][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-dg2-11/igt@kms_busy@basic@flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-dg2-11/igt@kms_busy@basic@flip.html * igt@kms_force_connector_basic@force-connector-state: - bat-adlm-1: [PASS][21] -> [ABORT][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-adlm-1/igt@kms_force_connector_basic@force-connector-state.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-adlm-1/igt@kms_force_connector_basic@force-connector-state.html - bat-rpls-1: [PASS][23] -> [ABORT][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-rpls-1/igt@kms_force_connector_basic@force-connector-state.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-rpls-1/igt@kms_force_connector_basic@force-connector-state.html - bat-mtlp-6: [PASS][25] -> [ABORT][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-mtlp-6/igt@kms_force_connector_basic@force-connector-state.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-mtlp-6/igt@kms_force_connector_basic@force-connector-state.html - bat-adls-5: [PASS][27] -> [ABORT][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-adls-5/igt@kms_force_connector_basic@force-connector-state.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-adls-5/igt@kms_force_connector_basic@force-connector-state.html #### Suppressed #### The following results come from untrusted machines, tests, or statuses. They do not affect the overall result. * igt@kms_busy@basic@flip: - {bat-dg2-14}: [PASS][29] -> [ABORT][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/bat-dg2-14/igt@kms_busy@basic@flip.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/bat-dg2-14/igt@kms_busy@basic@flip.html Known issues ------------ Here are the changes found in Patchwork_125508v1 that come from known issues: ### CI changes ### #### Issues hit #### * boot: - fi-bsw-n3050: [PASS][31] -> [FAIL][32] ([i915#8293]) [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/fi-bsw-n3050/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/fi-bsw-n3050/boot.html - fi-hsw-4770: [PASS][33] -> [FAIL][34] ([i915#8293]) [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/fi-hsw-4770/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/fi-hsw-4770/boot.html ### IGT changes ### #### Possible fixes #### * igt@kms_hdmi_inject@inject-audio: - fi-kbl-guc: [FAIL][35] ([IGT#3]) -> [PASS][36] [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13782/fi-kbl-guc/igt@kms_hdmi_inject@inject-audio.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/fi-kbl-guc/igt@kms_hdmi_inject@inject-audio.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3 [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293 Build changes ------------- * Linux: CI_DRM_13782 -> Patchwork_125508v1 CI-20190529: 20190529 CI_DRM_13782: 16c18fef1215015ab3d1a0dd3b06cf6131fe23bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7552: 557856802dfee103802f1157f97c65bb476d5468 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_125508v1: 16c18fef1215015ab3d1a0dd3b06cf6131fe23bd @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 8cac9ee88bc4 drm/i915/adl: Initialize all GV points as restricted in bw_state == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125508v1/index.html [-- Attachment #2: Type: text/html, Size: 8473 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-10-25 0:42 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-24 12:52 [Intel-gfx] [PATCH] drm/i915/adl: Initialize all GV points as restricted in bw_state Stanislav Lisovskiy 2023-10-24 13:04 ` Jani Nikula 2023-10-24 14:01 ` Ville Syrjälä 2023-10-24 14:50 ` Lisovskiy, Stanislav 2023-10-25 0:26 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork 2023-10-25 0:42 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.