Re: [Intel-gfx] [PATCH 22/42] drm/i915/xe2lpd: Add DC state support
> -Original Message-
> From: De Marchi, Lucas
> Sent: Wednesday, August 23, 2023 10:07 AM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Srivatsa, Anusha
> ; De Marchi, Lucas
> Subject: [PATCH 22/42] drm/i915/xe2lpd: Add DC state support
>
> From: Matt Roper
>
> Xe2_LPD supports DC5, DC6, and DC9 (DC3CO no longer exists). The overall
> programming and requirements to enter DC states are similar to those of
> Xe_LPD+ although AUX transactions do not require DC5/DC6 exit as they did
> previously.
>
> Bspec: 68851, 68857, 68886, 69115
> Cc: Anusha Srivatsa
> Signed-off-by: Matt Roper
> Signed-off-by: Lucas De Marchi
Reviewed-by: Anusha Srivatsa
> ---
> .../drm/i915/display/intel_display_power.c| 4 +++-
> .../i915/display/intel_display_power_map.c| 19 +++
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 7e2059abae9a..508a3225d9f0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -944,7 +944,9 @@ static u32 get_allowed_dc_mask(const struct
> drm_i915_private *dev_priv,
> if (!HAS_DISPLAY(dev_priv))
> return 0;
>
> - if (IS_DG2(dev_priv))
> + if (DISPLAY_VER(dev_priv) >= 20)
> + max_dc = 2;
> + else if (IS_DG2(dev_priv))
> max_dc = 1;
> else if (IS_DG1(dev_priv))
> max_dc = 3;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> index cef3b313c9f5..d74a742437c3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> @@ -1570,9 +1570,28 @@ static const struct i915_power_well_desc
> xe2lpd_power_wells_pica[] = {
> },
> };
>
> +I915_DECL_PW_DOMAINS(xe2lpd_pwdoms_dc_off,
> + POWER_DOMAIN_DC_OFF,
> + XELPD_PW_C_POWER_DOMAINS,
> + XELPD_PW_D_POWER_DOMAINS,
> + POWER_DOMAIN_AUDIO_MMIO,
> + POWER_DOMAIN_MODESET,
> + POWER_DOMAIN_INIT);
> +
> +static const struct i915_power_well_desc xe2lpd_power_wells_dcoff[] = {
> + {
> + .instances = _PW_INSTANCES(
> + I915_PW("DC_off", _pwdoms_dc_off,
> + .id = SKL_DISP_DC_OFF),
> + ),
> + .ops = _dc_off_power_well_ops,
> + },
> +};
> +
> static const struct i915_power_well_desc_list xe2lpd_power_wells[] = {
> I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
> I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
> + I915_PW_DESCRIPTORS(xe2lpd_power_wells_dcoff),
> I915_PW_DESCRIPTORS(xelpdp_power_wells_main),
> I915_PW_DESCRIPTORS(xe2lpd_power_wells_pica),
> };
> --
> 2.40.1
Re: [Intel-gfx] [PATCH 19/42] drm/i915/xe2lpd: Don't try to program PLANE_AUX_DIST
> -Original Message- > From: Intel-gfx On Behalf Of Lucas > De > Marchi > Sent: Wednesday, August 23, 2023 10:07 AM > To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc: De Marchi, Lucas ; Roper, Matthew D > > Subject: [Intel-gfx] [PATCH 19/42] drm/i915/xe2lpd: Don't try to program > PLANE_AUX_DIST > > From: Matt Roper > > Since Xe2LPD technically has FlatCCS, it doesn't have AuxCCS registers like > PLANE_AUX_DIST. However we currently have HAS_FLAT_CCS hardcoded to 0 > since compression isn't ready; we need to make sure this doesn't cause the > display code to go back to trying to write this register. > > Signed-off-by: Matt Roper > Signed-off-by: Lucas De Marchi Reviewed-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c > b/drivers/gpu/drm/i915/display/skl_universal_plane.c > index 3c212d8401c8..4dfd8b627147 100644 > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c > @@ -1254,7 +1254,7 @@ icl_plane_update_noarm(struct intel_plane *plane, > } > > /* FLAT CCS doesn't need to program AUX_DIST */ > - if (!HAS_FLAT_CCS(dev_priv)) > + if (!HAS_FLAT_CCS(dev_priv) && DISPLAY_VER(dev_priv) < 20) > intel_de_write_fw(dev_priv, PLANE_AUX_DIST(pipe, plane_id), > skl_plane_aux_dist(plane_state, color_plane)); > > -- > 2.40.1
Re: [Intel-gfx] [PATCH v3 14/14] drm/i915/adls: s/ADLS_RPLS/RAPTORLAKE_S in platform and subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
> ; Srivatsa, Anusha
>
> Subject: [PATCH v3 14/14] drm/i915/adls: s/ADLS_RPLS/RAPTORLAKE_S in
> platform and subplatform defines
>
> Driver refers to the platform Alderlake S as ADLS_RPLS in places and
> RAPTORLAKE_S in some.
>
> v2:
> - Unrolled wrapper IS_ADLS_GRAPHICS_STEP
>
> v3:
> - Replace IS_RAPTORLAKE_S instead of IS_ADLS_RPLS. (Tvrtko/Lucas).
> - Remove unused macro IS_ADLS_GRAPHICS/DISPLAY_STEP
> - Change the subject
>
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_display_device.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 9 +
> drivers/gpu/drm/i915/intel_step.c | 2 +-
> 4 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 8286e79522d1..dcb272327281 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -858,7 +858,7 @@ void intel_display_device_info_runtime_init(struct
> drm_i915_private *i915)
> BUILD_BUG_ON(BITS_PER_TYPE(display_runtime->port_mask) <
> I915_MAX_PORTS);
>
> /* Wa_14011765242: adl-s A0,A1 */
> - if (IS_ADLS_DISPLAY_STEP(i915, STEP_A0, STEP_A2))
> + if (IS_ALDERLAKE_S(i915) && IS_DISPLAY_STEP(i915, STEP_A0,
> STEP_A2))
> for_each_pipe(i915, pipe)
> display_runtime->num_scalers[pipe] = 0;
> else if (DISPLAY_VER(i915) >= 11) {
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index 18250fb64bd8..98b103375b7a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -43,7 +43,7 @@ static void uc_expand_default_options(struct intel_uc *uc)
> }
>
> /* Intermediate platforms are HuC authentication only */
> - if (IS_ALDERLAKE_S(i915) && !IS_ADLS_RPLS(i915)) {
> + if (IS_ALDERLAKE_S(i915) && !IS_RAPTORLAKE_S(i915)) {
> i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> return;
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 853687d9e3f8..9ddba8a8ab1a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -584,7 +584,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G11)
> #define IS_DG2_G12(i915) \
> IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G12) -
> #define IS_ADLS_RPLS(i915) \
> +#define IS_RAPTORLAKE_S(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_S,
> INTEL_SUBPLATFORM_RPL) #define IS_ALDERLAKE_P_N(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_N) @@ -654,13 +654,6 @@ IS_SUBPLATFORM(const
> struct drm_i915_private *i915,
>
>
>
> -#define IS_ADLS_DISPLAY_STEP(__i915, since, until) \
> - (IS_ALDERLAKE_S(__i915) && \
> - IS_DISPLAY_STEP(__i915, since, until))
> -
> -#define IS_ADLS_GRAPHICS_STEP(__i915, since, until) \
> - (IS_ALDERLAKE_S(__i915) && \
> - IS_GRAPHICS_STEP(__i915, since, until))
>
>
> #define IS_XEHPSDV_GRAPHICS_STEP(__i915, since, until) \ diff --git
> a/drivers/gpu/drm/i915/intel_step.c b/drivers/gpu/drm/i915/intel_step.c
> index 5553de469fa0..c02a6f156a00 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -201,7 +201,7 @@ void intel_step_init(struct drm_i915_private *i915)
> } else if (IS_ALDERLAKE_P(i915)) {
> revids = adlp_revids;
> size = ARRAY_SIZE(adlp_revids);
> - } else if (IS_ADLS_RPLS(i915)) {
> + } else if (IS_RAPTORLAKE_S(i915)) {
> revids = adls_rpls_revids;
> size = ARRAY_SIZE(adls_rpls_revids);
> } else if (IS_ALDERLAKE_S(i915)) {
> --
> 2.34.1
Re: [Intel-gfx] [PATCH v2 12/14] drm/i915/rplu: s/ADLP_RPLU/RAPTORLAKE_U in RPLU defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
> ; Srivatsa, Anusha
>
> Subject: [PATCH v2 12/14] drm/i915/rplu: s/ADLP_RPLU/RAPTORLAKE_U in
> RPLU defines
>
> Follow consistent naming convention. Replace ADLP with ALDERLAKE_P
>
> v2:
> - Replace IS_ADLP_RPLU with IS_RAPTORLAKE_U (Tvrtko/Lucas)
> - Change the subject
>
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 57113fb01fb2..2fb030b1ff1d 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -3570,7 +3570,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> if (IS_ALDERLAKE_P(dev_priv) && IS_DISPLAY_STEP(dev_priv,
> STEP_A0, STEP_B0)) {
> dev_priv->display.cdclk.table =
> adlp_a_step_cdclk_table;
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> - } else if (IS_ADLP_RPLU(dev_priv)) {
> + } else if (IS_RAPTORLAKE_U(dev_priv)) {
> dev_priv->display.cdclk.table = rplu_cdclk_table;
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> } else {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4e07ba69642d..d3a621e5a36b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -590,7 +590,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_N) #define IS_RAPTORLAKE_P(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_RPL) -#define IS_ADLP_RPLU(i915) \
> +#define IS_RAPTORLAKE_U(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_RPLU) #define IS_HASWELL_EARLY_SDV(i915)
> (IS_HASWELL(i915) && \
> (INTEL_DEVID(i915) & 0xFF00) == 0x0C00)
> --
> 2.34.1
Re: [Intel-gfx] [PATCH v2 11/14] drm/i915/rplp: s/ADLP_RPLP/RAPTORLAKE_P for RPLP defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
> ; Srivatsa, Anusha
>
> Subject: [PATCH v2 11/14] drm/i915/rplp: s/ADLP_RPLP/RAPTORLAKE_P for
> RPLP defines
>
> Follow consistent naming convention. Replace ADLP with ALDERLAKE_P.
>
> v2:
> - Replace IS_ADLP_RPLP with IS_RAPTORLAKE_P. (Tvrtko/Lucas)
> - Change the subject
>
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_step.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c24be1875769..4e07ba69642d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -588,7 +588,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_S,
> INTEL_SUBPLATFORM_RPL) #define IS_ADLP_N(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_N) -#define IS_ADLP_RPLP(i915) \
> +#define IS_RAPTORLAKE_P(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_RPL) #define IS_ADLP_RPLU(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_RPLU) diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index 4ca22d0c945b..7601122765b7 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -195,7 +195,7 @@ void intel_step_init(struct drm_i915_private *i915)
> } else if (IS_ADLP_N(i915)) {
> revids = adlp_n_revids;
> size = ARRAY_SIZE(adlp_n_revids);
> - } else if (IS_ADLP_RPLP(i915)) {
> + } else if (IS_RAPTORLAKE_P(i915)) {
> revids = adlp_rplp_revids;
> size = ARRAY_SIZE(adlp_rplp_revids);
> } else if (IS_ALDERLAKE_P(i915)) {
> --
> 2.34.1
Re: [Intel-gfx] [PATCH v3 07/14] drm/i915/rkl: s/RKL/ROCKETLAKE for platform/subplatform defines
> -Original Message- > From: Bhadane, Dnyaneshwar > Sent: Wednesday, July 26, 2023 1:07 PM > To: intel-gfx@lists.freedesktop.org > Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com; > Srivatsa, Anusha ; Atwood, Matthew S > ; Roper, Matthew D > ; Bhadane, Dnyaneshwar > ; Srivatsa, Anusha > > Subject: [PATCH v3 07/14] drm/i915/rkl: s/RKL/ROCKETLAKE for > platform/subplatform defines > > Follow consistent naming convention. Replace RKL with ROCKETLAKE.Replace > IS_RKL_GRAPHICS_STEP with IS_ROCKETLAKE && IS_DISPLAY_STEP. > > v2: > - s/RKL/rkl in the subject prefix(Anusha) > > v3: > - Unrolled wrapper IS_RKL_DISPLAY_STEP. > - Replace IS_PLATFORM && IS_DISPLAY_STEP (Jani/Tvrtko) > > Cc: Tvrtko Ursulin > Cc: Jani Nikula > Cc: Anusha Srivatsa > Signed-off-by: Dnyaneshwar Bhadane Reviewed-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- > drivers/gpu/drm/i915/i915_drv.h| 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > b/drivers/gpu/drm/i915/display/intel_display_power.c > index 38225e5d311e..9e01054c2430 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > @@ -1609,7 +1609,7 @@ static void tgl_bw_buddy_init(struct > drm_i915_private *dev_priv) > return; > > if (IS_ALDERLAKE_S(dev_priv) || > - IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > + (IS_ROCKETLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, STEP_A0, > +STEP_B0))) > /* Wa_1409767108 */ > table = wa_1409767108_buddy_page_masks; > else > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index e6f77498d46c..f46846574420 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -660,8 +660,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > (IS_TIGERLAKE(__i915) && \ >IS_DISPLAY_STEP(__i915, since, until)) > > -#define IS_RKL_DISPLAY_STEP(p, since, until) \ > - (IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until)) > > #define IS_ADLS_DISPLAY_STEP(__i915, since, until) \ > (IS_ALDERLAKE_S(__i915) && \ > -- > 2.34.1
Re: [Intel-gfx] [PATCH v4 04/14] drm/i915/kbl: s/KBL/KABYLAKE for platform/subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 12:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH v4 04/14] drm/i915/kbl: s/KBL/KABYLAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace KBL with KABYLAKE.Replace
> IS_KBL_GRAPHICS_STEP with IS_KABYLAKE () && IS_GRAPHICS_STEP().
>
> v2:
> - s/KBL/kbl in the subject prefix(Anusha)
>
> v3:
> - Unrolled wrapper IS_KBL_GRAPHICS_STEP.
> - Replace with IS_PLATFORM && DISPLAY_STEP(tvrtko/jani)
>
> v4:
> - Removed unused macro.
>
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c| 6 +++---
> drivers/gpu/drm/i915/i915_drv.h| 12
> drivers/gpu/drm/i915/intel_clock_gating.c | 4 ++--
> 5 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index e85eab21b09d..39eab9ea02dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1740,9 +1740,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder
> *encoder)
> encoder->get_buf_trans = icl_get_mg_buf_trans;
> } else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
> encoder->get_buf_trans = bxt_get_buf_trans;
> - } else if (IS_CML_ULX(i915) || IS_CFL_ULX(i915) || IS_KBL_ULX(i915)) {
> + } else if (IS_CML_ULX(i915) || IS_CFL_ULX(i915) ||
> +IS_KABYLAKE_ULX(i915)) {
> encoder->get_buf_trans = kbl_y_get_buf_trans;
> - } else if (IS_CML_ULT(i915) || IS_CFL_ULT(i915) || IS_KBL_ULT(i915)) {
> + } else if (IS_CML_ULT(i915) || IS_CFL_ULT(i915) ||
> +IS_KABYLAKE_ULT(i915)) {
> encoder->get_buf_trans = kbl_u_get_buf_trans;
> } else if (IS_COMETLAKE(i915) || IS_COFFEELAKE(i915) ||
> IS_KABYLAKE(i915)) {
> encoder->get_buf_trans = kbl_get_buf_trans; diff --git
> a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 23857cc08eca..971cddb6d760 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -43,7 +43,7 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32
> mode)
> vf_flush_wa = true;
>
> /* WaForGAMHang:kbl */
> - if (IS_KBL_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
> + if (IS_KABYLAKE(rq->engine->i915) &&
> +IS_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
> dc_flush_wa = true;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 85176eabcda0..3b4a5b49418d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -600,7 +600,7 @@ static void kbl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> gen9_ctx_workarounds_init(engine, wal);
>
> /* WaToEnableHwFixForPushConstHWBug:kbl */
> - if (IS_KBL_GRAPHICS_STEP(i915, STEP_C0, STEP_FOREVER))
> + if (IS_KABYLAKE(i915) && IS_GRAPHICS_STEP(i915, STEP_C0,
> +STEP_FOREVER))
> wa_masked_en(wal, COMMON_SLICE_CHICKEN2,
>GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
>
> @@ -1204,7 +1204,7 @@ kbl_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> gen9_gt_workarounds_init(gt, wal);
>
> /* WaDisableDynamicCreditSharing:kbl */
> - if (IS_KBL_GRAPHICS_STEP(gt->i915, 0, STEP_C0))
> + if (IS_KABYLAKE(gt->i915) && IS_GRAPHICS_STEP(gt->i915, 0, STEP_C0))
> wa_write_or(wal,
> GAMT_CHKN_BIT_REG,
>
> GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING);
> @@ -2945,7 +2945,7 @@ xcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> struct drm_i915_private *i915 = engine->i915;
>
> /* WaKBLVECSSemaphoreWaitPoll:kbl */
> - if (IS_KBL_GRAPHICS_STEP(i915, STEP_A0, STEP_F0)) {
> + if (IS_KABYLAKE(i915) && IS_GRAPHICS_STEP(i915, STEP_A0, STEP_F0)) {
>
Re: [Intel-gfx] [PATCH v3 07/14] drm/i915/rkl: s/RKL/ROCKETLAKE for platform/subplatform defines
> -Original Message- > From: Bhadane, Dnyaneshwar > Sent: Wednesday, July 26, 2023 12:33 PM > To: intel-gfx@lists.freedesktop.org > Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com; > Srivatsa, Anusha ; Atwood, Matthew S > ; Roper, Matthew D > ; Bhadane, Dnyaneshwar > ; Srivatsa, Anusha > > Subject: [PATCH v3 07/14] drm/i915/rkl: s/RKL/ROCKETLAKE for > platform/subplatform defines > > Follow consistent naming convention. Replace RKL with ROCKETLAKE.Replace > IS_RKL_GRAPHICS_STEP with IS_ROCKETLAKE && IS_DISPLAY_STEP. > > v2: > - s/RKL/rkl in the subject prefix(Anusha) > > v3: > - Unrolled wrapper IS_RKL_DISPLAY_STEP. > - Replace IS_PLATFORM && IS_DISPLAY_STEP (Jani/Tvrtko) > > Cc: Tvrtko Ursulin > Cc: Jani Nikula > Cc: Anusha Srivatsa > Signed-off-by: Dnyaneshwar Bhadane This version is indeed neat and not sore to the eye at all. Thanks for this: Reviewed-by: Anusha Srivatsa > > --- > drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- > drivers/gpu/drm/i915/i915_drv.h| 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > b/drivers/gpu/drm/i915/display/intel_display_power.c > index 38225e5d311e..9e01054c2430 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > @@ -1609,7 +1609,7 @@ static void tgl_bw_buddy_init(struct > drm_i915_private *dev_priv) > return; > > if (IS_ALDERLAKE_S(dev_priv) || > - IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > + (IS_ROCKETLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, STEP_A0, > +STEP_B0))) > /* Wa_1409767108 */ > table = wa_1409767108_buddy_page_masks; > else > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index e6f77498d46c..f46846574420 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -660,8 +660,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > (IS_TIGERLAKE(__i915) && \ >IS_DISPLAY_STEP(__i915, since, until)) > > -#define IS_RKL_DISPLAY_STEP(p, since, until) \ > - (IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until)) > > #define IS_ADLS_DISPLAY_STEP(__i915, since, until) \ > (IS_ALDERLAKE_S(__i915) && \ > -- > 2.34.1
Re: [Intel-gfx] [PATCH v4 06/14] drm/i915/cml: s/CML/COMETLAKE for platform/subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH v4 06/14] drm/i915/cml: s/CML/COMETLAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace CML with COMETLAKE.
>
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
> drivers/gpu/drm/i915/i915_drv.h| 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index cd85b9fed129..35e6e3a5ddf1 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1740,9 +1740,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder
> *encoder)
> encoder->get_buf_trans = icl_get_mg_buf_trans;
> } else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
> encoder->get_buf_trans = bxt_get_buf_trans;
> - } else if (IS_CML_ULX(i915) || IS_COFFEELAKE_ULX(i915) ||
> IS_KABYLAKE_ULX(i915)) {
> + } else if (IS_COMETLAKE_ULX(i915) || IS_COFFEELAKE_ULX(i915) ||
> +IS_KABYLAKE_ULX(i915)) {
> encoder->get_buf_trans = kbl_y_get_buf_trans;
> - } else if (IS_CML_ULT(i915) || IS_COFFEELAKE_ULT(i915) ||
> IS_KABYLAKE_ULT(i915)) {
> + } else if (IS_COMETLAKE_ULT(i915) || IS_COFFEELAKE_ULT(i915) ||
> +IS_KABYLAKE_ULT(i915)) {
> encoder->get_buf_trans = kbl_u_get_buf_trans;
> } else if (IS_COMETLAKE(i915) || IS_COFFEELAKE(i915) ||
> IS_KABYLAKE(i915)) {
> encoder->get_buf_trans = kbl_get_buf_trans; diff --git
> a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index
> 04107696e966..e6f77498d46c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -636,11 +636,11 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> #define IS_COFFEELAKE_GT3(i915) (IS_COFFEELAKE(i915) && \
>INTEL_INFO(i915)->gt == 3)
>
> -#define IS_CML_ULT(i915) \
> +#define IS_COMETLAKE_ULT(i915) \
> IS_SUBPLATFORM(i915, INTEL_COMETLAKE,
> INTEL_SUBPLATFORM_ULT) -#define IS_CML_ULX(i915) \
> +#define IS_COMETLAKE_ULX(i915) \
> IS_SUBPLATFORM(i915, INTEL_COMETLAKE,
> INTEL_SUBPLATFORM_ULX)
> -#define IS_CML_GT2(i915) (IS_COMETLAKE(i915) && \
> +#define IS_COMETLAKE_GT2(i915) (IS_COMETLAKE(i915) && \
>INTEL_INFO(i915)->gt == 2)
>
> #define IS_ICL_WITH_PORT_F(i915) \
> --
> 2.34.1
Re: [Intel-gfx] [PATCH v1 05/14] drm/i915/cfl: s/CFL/COFFEELAKE for platform/subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH v1 05/14] drm/i915/cfl: s/CFL/COFFEELAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace CFL with COFFEELAKE.
>
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
> drivers/gpu/drm/i915/i915_drv.h| 8
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index 39eab9ea02dd..cd85b9fed129 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1740,9 +1740,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder
> *encoder)
> encoder->get_buf_trans = icl_get_mg_buf_trans;
> } else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
> encoder->get_buf_trans = bxt_get_buf_trans;
> - } else if (IS_CML_ULX(i915) || IS_CFL_ULX(i915) ||
> IS_KABYLAKE_ULX(i915)) {
> + } else if (IS_CML_ULX(i915) || IS_COFFEELAKE_ULX(i915) ||
> +IS_KABYLAKE_ULX(i915)) {
> encoder->get_buf_trans = kbl_y_get_buf_trans;
> - } else if (IS_CML_ULT(i915) || IS_CFL_ULT(i915) ||
> IS_KABYLAKE_ULT(i915)) {
> + } else if (IS_CML_ULT(i915) || IS_COFFEELAKE_ULT(i915) ||
> +IS_KABYLAKE_ULT(i915)) {
> encoder->get_buf_trans = kbl_u_get_buf_trans;
> } else if (IS_COMETLAKE(i915) || IS_COFFEELAKE(i915) ||
> IS_KABYLAKE(i915)) {
> encoder->get_buf_trans = kbl_get_buf_trans; diff --git
> a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index
> ba075bb183db..04107696e966 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -627,13 +627,13 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
>INTEL_INFO(i915)->gt == 2)
> #define IS_KABYLAKE_GT3(i915)(IS_KABYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 3)
> -#define IS_CFL_ULT(i915) \
> +#define IS_COFFEELAKE_ULT(i915) \
> IS_SUBPLATFORM(i915, INTEL_COFFEELAKE,
> INTEL_SUBPLATFORM_ULT) -#define IS_CFL_ULX(i915) \
> +#define IS_COFFEELAKE_ULX(i915) \
> IS_SUBPLATFORM(i915, INTEL_COFFEELAKE,
> INTEL_SUBPLATFORM_ULX)
> -#define IS_CFL_GT2(i915) (IS_COFFEELAKE(i915) && \
> +#define IS_COFFEELAKE_GT2(i915) (IS_COFFEELAKE(i915) && \
>INTEL_INFO(i915)->gt == 2)
> -#define IS_CFL_GT3(i915) (IS_COFFEELAKE(i915) && \
> +#define IS_COFFEELAKE_GT3(i915) (IS_COFFEELAKE(i915) && \
>INTEL_INFO(i915)->gt == 3)
>
> #define IS_CML_ULT(i915) \
> --
> 2.34.1
Re: [Intel-gfx] [PATCH v4 04/14] drm/i915/kbl: s/KBL/KABYLAKE for platform/subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 12:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH v4 04/14] drm/i915/kbl: s/KBL/KABYLAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace KBL with KABYLAKE.Replace
> IS_KBL_GRAPHICS_STEP with IS_KABYLAKE () && IS_GRAPHICS_STEP().
>
> v2:
> - s/KBL/kbl in the subject prefix(Anusha)
>
> v3:
> - Unrolled wrapper IS_KBL_GRAPHICS_STEP.
> - Replace with IS_PLATFORM && DISPLAY_STEP(tvrtko/jani)
>
> v4:
> - Removed unused macro.
>
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c| 6 +++---
> drivers/gpu/drm/i915/i915_drv.h| 12
> drivers/gpu/drm/i915/intel_clock_gating.c | 4 ++--
> 5 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index e85eab21b09d..39eab9ea02dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1740,9 +1740,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder
> *encoder)
> encoder->get_buf_trans = icl_get_mg_buf_trans;
> } else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
> encoder->get_buf_trans = bxt_get_buf_trans;
> - } else if (IS_CML_ULX(i915) || IS_CFL_ULX(i915) || IS_KBL_ULX(i915)) {
> + } else if (IS_CML_ULX(i915) || IS_CFL_ULX(i915) ||
> +IS_KABYLAKE_ULX(i915)) {
> encoder->get_buf_trans = kbl_y_get_buf_trans;
> - } else if (IS_CML_ULT(i915) || IS_CFL_ULT(i915) || IS_KBL_ULT(i915)) {
> + } else if (IS_CML_ULT(i915) || IS_CFL_ULT(i915) ||
> +IS_KABYLAKE_ULT(i915)) {
> encoder->get_buf_trans = kbl_u_get_buf_trans;
> } else if (IS_COMETLAKE(i915) || IS_COFFEELAKE(i915) ||
> IS_KABYLAKE(i915)) {
> encoder->get_buf_trans = kbl_get_buf_trans; diff --git
> a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 23857cc08eca..971cddb6d760 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -43,7 +43,7 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32
> mode)
> vf_flush_wa = true;
>
> /* WaForGAMHang:kbl */
> - if (IS_KBL_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
> + if (IS_KABYLAKE(rq->engine->i915) &&
> +IS_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
> dc_flush_wa = true;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 85176eabcda0..3b4a5b49418d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -600,7 +600,7 @@ static void kbl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> gen9_ctx_workarounds_init(engine, wal);
>
> /* WaToEnableHwFixForPushConstHWBug:kbl */
> - if (IS_KBL_GRAPHICS_STEP(i915, STEP_C0, STEP_FOREVER))
> + if (IS_KABYLAKE(i915) && IS_GRAPHICS_STEP(i915, STEP_C0,
> +STEP_FOREVER))
> wa_masked_en(wal, COMMON_SLICE_CHICKEN2,
>GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
>
> @@ -1204,7 +1204,7 @@ kbl_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> gen9_gt_workarounds_init(gt, wal);
>
> /* WaDisableDynamicCreditSharing:kbl */
> - if (IS_KBL_GRAPHICS_STEP(gt->i915, 0, STEP_C0))
> + if (IS_KABYLAKE(gt->i915) && IS_GRAPHICS_STEP(gt->i915, 0, STEP_C0))
> wa_write_or(wal,
> GAMT_CHKN_BIT_REG,
>
> GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING);
> @@ -2945,7 +2945,7 @@ xcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> struct drm_i915_private *i915 = engine->i915;
>
> /* WaKBLVECSSemaphoreWaitPoll:kbl */
> - if (IS_KBL_GRAPHICS_STEP(i915, STEP_A0, STEP_F0)) {
> + if (IS_KABYLAKE(i915) && IS_GRAPHICS_STEP(i915, STEP_A0, STEP_F0)) {
>
Re: [Intel-gfx] [PATCH v4 03/14] drm/i915/skl: s/SKL/SKYLAKE for platform/subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
> ; Srivatsa, Anusha
>
> Subject: [PATCH v4 03/14] drm/i915/skl: s/SKL/SKYLAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace SKL with SKYLAKE and Replace
> IS_SKL_GRAPHICS_STEP with
> IS_SKYLAKE() && IS_GRAPHICS_STEP().
>
> v2:
> - Change subject skl instead of SKL(Anusha)
>
> v3:
> - Unrolled wrapper IS_SKL_GRAPHICS_STEP.
> - Replace with IS_PLATFORM && DISPLAY_STEP(tvrtko/jani)
>
> v4:
> - Removed the unused macro.
>
> Cc: Anusha Srivatsa
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
>
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 13 ++---
> 3 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index 5b2665a9d86d..e85eab21b09d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1746,9 +1746,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder
> *encoder)
> encoder->get_buf_trans = kbl_u_get_buf_trans;
> } else if (IS_COMETLAKE(i915) || IS_COFFEELAKE(i915) ||
> IS_KABYLAKE(i915)) {
> encoder->get_buf_trans = kbl_get_buf_trans;
> - } else if (IS_SKL_ULX(i915)) {
> + } else if (IS_SKYLAKE_ULX(i915)) {
> encoder->get_buf_trans = skl_y_get_buf_trans;
> - } else if (IS_SKL_ULT(i915)) {
> + } else if (IS_SKYLAKE_ULT(i915)) {
> encoder->get_buf_trans = skl_u_get_buf_trans;
> } else if (IS_SKYLAKE(i915)) {
> encoder->get_buf_trans = skl_get_buf_trans; diff --git
> a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 9634ab8d738b..b0b7d448364a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1192,7 +1192,7 @@ skl_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
>
> /* WaInPlaceDecompressionHang:skl */
> - if (IS_SKL_GRAPHICS_STEP(gt->i915, STEP_A0, STEP_H0))
> + if (IS_SKYLAKE(gt->i915) && IS_GRAPHICS_STEP(gt->i915, STEP_A0,
> +STEP_H0))
> wa_write_or(wal,
> GEN9_GAMT_ECO_REG_RW_IA,
> GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6607f233461a..d7f7ca135000 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -609,19 +609,19 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> /* ULX machines are also considered ULT. */ #define IS_HASWELL_ULX(i915) \
> IS_SUBPLATFORM(i915, INTEL_HASWELL, INTEL_SUBPLATFORM_ULX) -
> #define IS_SKL_ULT(i915) \
> +#define IS_SKYLAKE_ULT(i915) \
> IS_SUBPLATFORM(i915, INTEL_SKYLAKE, INTEL_SUBPLATFORM_ULT) -
> #define IS_SKL_ULX(i915) \
> +#define IS_SKYLAKE_ULX(i915) \
> IS_SUBPLATFORM(i915, INTEL_SKYLAKE, INTEL_SUBPLATFORM_ULX)
> #define IS_KBL_ULT(i915) \
> IS_SUBPLATFORM(i915, INTEL_KABYLAKE, INTEL_SUBPLATFORM_ULT)
> #define IS_KBL_ULX(i915) \
> IS_SUBPLATFORM(i915, INTEL_KABYLAKE, INTEL_SUBPLATFORM_ULX)
> -#define IS_SKL_GT2(i915) (IS_SKYLAKE(i915) && \
> +#define IS_SKYLAKE_GT2(i915) (IS_SKYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 2)
> -#define IS_SKL_GT3(i915) (IS_SKYLAKE(i915) && \
> +#define IS_SKYLAKE_GT3(i915) (IS_SKYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 3)
> -#define IS_SKL_GT4(i915) (IS_SKYLAKE(i915) && \
> +#define IS_SKYLAKE_GT4(i915) (IS_SKYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 4)
> #define IS_KBL_GT2(i915) (IS_KABYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 2)
> @@ -649,7 +649,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_TGL_UY(i915) \
> IS_SUBPLATFORM(i915, INTEL_TIGERLAKE, INTEL_SUBPLATFORM_UY)
>
> -#define IS_SKL_GRAPHICS_STEP(p, since
Re: [Intel-gfx] [PATCH v1 02/14] drm/i915/bdw: s/BDW/BROADWELL for platform/subplatform defines
> -Original Message- > From: Bhadane, Dnyaneshwar > Sent: Wednesday, July 26, 2023 1:07 PM > To: intel-gfx@lists.freedesktop.org > Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com; > Srivatsa, Anusha ; Atwood, Matthew S > ; Roper, Matthew D > ; Bhadane, Dnyaneshwar > > Subject: [PATCH v1 02/14] drm/i915/bdw: s/BDW/BROADWELL for > platform/subplatform defines > > Follow consistent naming convention. Replace BDW with BROADWELL. > > Signed-off-by: Dnyaneshwar Bhadane Thanks for the effort, Reviewed-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++-- > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +- > drivers/gpu/drm/i915/i915_drv.h | 6 +++--- > drivers/gpu/drm/i915/soc/intel_pch.c | 10 +- > 5 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c > b/drivers/gpu/drm/i915/display/intel_cdclk.c > index f18e1f8ef22e..f683802ce931 100644 > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c > @@ -3200,9 +3200,9 @@ void intel_update_max_cdclk(struct drm_i915_private > *dev_priv) >*/ > if (intel_de_read(dev_priv, FUSE_STRAP) & HSW_CDCLK_LIMIT) > dev_priv->display.cdclk.max_cdclk_freq = 45; > - else if (IS_BDW_ULX(dev_priv)) > + else if (IS_BROADWELL_ULX(dev_priv)) > dev_priv->display.cdclk.max_cdclk_freq = 45; > - else if (IS_BDW_ULT(dev_priv)) > + else if (IS_BROADWELL_ULT(dev_priv)) > dev_priv->display.cdclk.max_cdclk_freq = 54; > else > dev_priv->display.cdclk.max_cdclk_freq = 675000; diff - > -git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 6352c530bd7b..e401bcb234c2 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -7377,7 +7377,7 @@ static bool intel_ddi_crt_present(struct > drm_i915_private *dev_priv) > if (DISPLAY_VER(dev_priv) >= 9) > return false; > > - if (IS_HASWELL_ULT(dev_priv) || IS_BDW_ULT(dev_priv)) > + if (IS_HASWELL_ULT(dev_priv) || IS_BROADWELL_ULT(dev_priv)) > return false; > > if (HAS_PCH_LPT_H(dev_priv) && > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 589d009032fc..9634ab8d738b 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -420,7 +420,7 @@ static void bdw_ctx_workarounds_init(struct > intel_engine_cs *engine, >/* WaForceContextSaveRestoreNonCoherent:bdw */ >HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT | >/* WaDisableFenceDestinationToSLM:bdw (pre-prod) */ > - (IS_BDW_GT3(i915) ? HDC_FENCE_DEST_SLM_DISABLE : 0)); > + (IS_BROADWELL_GT3(i915) ? > HDC_FENCE_DEST_SLM_DISABLE : 0)); > } > > static void chv_ctx_workarounds_init(struct intel_engine_cs *engine, diff > --git > a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index > 1003154ec71e..6607f233461a 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -594,11 +594,11 @@ IS_SUBPLATFORM(const struct drm_i915_private > *i915, > IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P, > INTEL_SUBPLATFORM_RPLU) #define IS_HASWELL_EARLY_SDV(i915) > (IS_HASWELL(i915) && \ > (INTEL_DEVID(i915) & 0xFF00) == 0x0C00) - > #define IS_BDW_ULT(i915) \ > +#define IS_BROADWELL_ULT(i915) \ > IS_SUBPLATFORM(i915, INTEL_BROADWELL, > INTEL_SUBPLATFORM_ULT) -#define IS_BDW_ULX(i915) \ > +#define IS_BROADWELL_ULX(i915) \ > IS_SUBPLATFORM(i915, INTEL_BROADWELL, > INTEL_SUBPLATFORM_ULX) > -#define IS_BDW_GT3(i915) (IS_BROADWELL(i915) && \ > +#define IS_BROADWELL_GT3(i915) (IS_BROADWELL(i915) && \ >INTEL_INFO(i915)->gt == 3) > #define IS_HASWELL_ULT(i915) \ > IS_SUBPLATFORM(i915, INTEL_HASWELL, INTEL_SUBPLATFORM_ULT) > diff --git a/drivers/gpu/drm/i915/soc/intel_pch.c > b/drivers/gpu/drm/i915/soc/intel_pch.c > index bf829f85be7e..382a4a8015b4 100644 > --- a/drivers/gpu/drm/i915/soc/intel_pch.c > +++ b/drivers/gpu/drm/i915/soc/intel_pch.c > @@ -32,21 +32,21 @@ intel_pch_type(const struct drm_i915_private > *dev_priv, unsigned short
Re: [Intel-gfx] [PATCH v1 01/14] drm/i915/hsw: s/HSW/HASWELL for platform/subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, July 26, 2023 1:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Atwood, Matthew S
> ; Roper, Matthew D
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH v1 01/14] drm/i915/hsw: s/HSW/HASWELL for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace HSW with HASWELL.
>
> Signed-off-by: Dnyaneshwar Bhadane
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c| 2 +-
> drivers/gpu/drm/i915/display/intel_display_device.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
> drivers/gpu/drm/i915/display/intel_pch_refclk.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
> drivers/gpu/drm/i915/i915_driver.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 12 ++--
> drivers/gpu/drm/i915/soc/intel_pch.c| 10 +-
> 10 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index dcc1f6941b60..f18e1f8ef22e 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -470,7 +470,7 @@ static void hsw_get_cdclk(struct drm_i915_private
> *dev_priv,
> cdclk_config->cdclk = 45;
> else if (freq == LCPLL_CLK_FREQ_450)
> cdclk_config->cdclk = 45;
> - else if (IS_HSW_ULT(dev_priv))
> + else if (IS_HASWELL_ULT(dev_priv))
> cdclk_config->cdclk = 337500;
> else
> cdclk_config->cdclk = 54;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 43cba98f7753..6352c530bd7b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7377,7 +7377,7 @@ static bool intel_ddi_crt_present(struct
> drm_i915_private *dev_priv)
> if (DISPLAY_VER(dev_priv) >= 9)
> return false;
>
> - if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> + if (IS_HASWELL_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> return false;
>
> if (HAS_PCH_LPT_H(dev_priv) &&
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h
> b/drivers/gpu/drm/i915/display/intel_display_device.h
> index 3324bd453ca7..215e682bd8b7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
> @@ -54,7 +54,7 @@ struct drm_printer;
> #define HAS_GMCH(i915) (DISPLAY_INFO(i915)-
> >has_gmch)
> #define HAS_HW_SAGV_WM(i915) (DISPLAY_VER(i915) >= 13 &&
> !IS_DGFX(i915))
> #define HAS_IPC(i915)(DISPLAY_INFO(i915)->has_ipc)
> -#define HAS_IPS(i915)(IS_HSW_ULT(i915) ||
> IS_BROADWELL(i915))
> +#define HAS_IPS(i915)(IS_HASWELL_ULT(i915) ||
> IS_BROADWELL(i915))
> #define HAS_LSPCON(i915) (IS_DISPLAY_VER(i915, 9, 10))
> #define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915) ||
> DISPLAY_VER(i915) >= 14)
> #define HAS_MSO(i915)(DISPLAY_VER(i915) >= 12)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 03675620e3ea..f5407569300a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -510,7 +510,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
> } else if (DISPLAY_VER(dev_priv) == 9) {
> source_rates = skl_rates;
> size = ARRAY_SIZE(skl_rates);
> - } else if ((IS_HASWELL(dev_priv) && !IS_HSW_ULX(dev_priv)) ||
> + } else if ((IS_HASWELL(dev_priv) && !IS_HASWELL_ULX(dev_priv)) ||
> IS_BROADWELL(dev_priv)) {
> source_rates = hsw_rates;
> size = ARRAY_SIZE(hsw_rates);
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 6b2d8a1e2aa9..66afdb91fcdf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -927,7 +927,7 @@ static int hsw_ddi_wrpll_get_freq(struct
> drm_i915_private *dev_priv,
> switch (wrpll & WRPLL_REF_MASK) {
>
Re: [Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform defines
I Like the acronym replacement approach - despite making the macro names
longer, it is consistent with how platform is referred everywhere in the driver.
For that,
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Monday, July 10, 2023 6:44 AM
> To: intel-gfx@lists.freedesktop.org; Ursulin, Tvrtko
>
> Cc: jani.nik...@linux.intel.com; Srivatsa, Anusha
> Subject: RE: [v3] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform
> defines
>
>
>
> > -Original Message-
> > From: Bhadane, Dnyaneshwar
> > Sent: Monday, July 10, 2023 4:28 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Ursulin, Tvrtko ;
> > jani.nik...@linux.intel.com; Srivatsa, Anusha
> > ; Bhadane, Dnyaneshwar
> >
> > Subject: [v3] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform
> > defines
> >
> > Follow consistent naming convention. Replace MTL with METEORLAKE.
> > Added defines that are replacing IS_MTL_GRAPHICS_STEP with
> > IS_METEORLAKE_P_GRAPHICS_STEP and
> IS_METEORLAKE_M_GRAPHICS_STEP.
> > Also replaced IS_METEORLAKE_MEDIA_STEP instead of IS_MTL_MEDIA_STEP
> > and IS_METEORLAKE_DISPLAY_STEP instead of IS_MTL_DISPLAY_STEP.
> >
> Hi Tvrtko,
> Could you please give the feedback on this ? or suggestion regarding the
> approach.
>
> > v2:
> > - Replace IS_MTL_GRAPHICS_STEP with
> > IS_METEROLAKE_(P/M)_GRAPHICS_STEP (Tvrtko).
> > - Changed subject prefix mtl instead of MTL (Anusha)
> > v3:
> > - Updated the commit message. (Anusha)
> >
> > Cc: Tvrtko Ursulin
> > Cc: Jani Nikula
> > Cc: Anusha Srivatsa
> > Signed-off-by: Dnyaneshwar Bhadane
> > ---
> > drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_pmdemand.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_psr.c | 10 ++---
> > .../drm/i915/display/skl_universal_plane.c| 4 +-
> > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 8 ++--
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> > .../drm/i915/gt/intel_execlists_submission.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 4 +-
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +-
> > drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +-
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 44 +--
> > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +-
> > drivers/gpu/drm/i915/i915_drv.h | 15 +--
> > drivers/gpu/drm/i915/i915_perf.c | 4 +-
> > 15 files changed, 60 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 7f8b2d7713c7..6358a8b26172 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -1093,7 +1093,7 @@ static int intel_fbc_check_plane(struct
> > intel_atomic_state *state,
> >
> > /* Wa_14016291713 */
> > if ((IS_DISPLAY_VER(i915, 12, 13) ||
> > -IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
> > +IS_METEORLAKE_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
> > crtc_state->has_psr) {
> > plane_state->no_fbc_reason = "PSR1 enabled
> (Wa_14016291713)";
> > return 0;
> > diff --git a/drivers/gpu/drm/i915/display/intel_pmdemand.c
> > b/drivers/gpu/drm/i915/display/intel_pmdemand.c
> > index f7608d363634..8c3158b188ef 100644
> > --- a/drivers/gpu/drm/i915/display/intel_pmdemand.c
> > +++ b/drivers/gpu/drm/i915/display/intel_pmdemand.c
> > @@ -92,7 +92,7 @@ int intel_pmdemand_init(struct drm_i915_private *i915)
> > _state->base,
> > _pmdemand_funcs);
> >
> > - if (IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
> > + if (IS_METEORLAKE_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
> > /* Wa_14016740474 */
> > intel_de_rmw(i915, XELPD_CHICKEN_DCPR_3, 0,
> > DMD_RSP_TIMEOUT_DISABLE);
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 62151abe4748..ecd4e36119b2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1247,7 +1247,7 @@ static void wm_optimization_wa(struct intel_dp
> > *intel_dp,
> > bool set_wa_bit = false;
> >
> >
Re: [Intel-gfx] [v2] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Friday, June 30, 2023 4:40 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com;
> Srivatsa, Anusha ; Bhadane, Dnyaneshwar
>
> Subject: [v2] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform
> defines
>
> Follow consistent naming convention. Replace MTL with METEORLAKE. Added
> defines that are replacing IS_MTL_GRAPHICS_STEP with
> IS_METEORLAKE_P_GRAPHICS_STEP and IS_METEORLAKE_M_GRAPHICS_STEP.
The patch also changes MTL_MEDIA macros. That should be mentioned in the commit
message.
> v2:
> - Replace IS_MLT_GRAPHICS_STEP with
Typo ^ s/MLT/MTL
> IS_METEROLAKE_(P/M)_GRAPHICS_STEP (Tvrtko).
> - Changed subject prefix mtl with MTL (Anusha)
Rewording:"mtl instead of MTL" or "use lower case instead of upper case"
Anusha
>
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Anusha Srivatsa
>
> Signed-off-by: Dnyaneshwar Bhadane
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_pmdemand.c | 2 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 10 ++---
> .../drm/i915/display/skl_universal_plane.c| 4 +-
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 8 ++--
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> .../drm/i915/gt/intel_execlists_submission.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 4 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 44 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +-
> drivers/gpu/drm/i915/i915_drv.h | 15 +--
> drivers/gpu/drm/i915/i915_perf.c | 4 +-
> 15 files changed, 60 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 7f8b2d7713c7..6358a8b26172 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1093,7 +1093,7 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
>
> /* Wa_14016291713 */
> if ((IS_DISPLAY_VER(i915, 12, 13) ||
> - IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
> + IS_METEORLAKE_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
> crtc_state->has_psr) {
> plane_state->no_fbc_reason = "PSR1 enabled
> (Wa_14016291713)";
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_pmdemand.c
> b/drivers/gpu/drm/i915/display/intel_pmdemand.c
> index f7608d363634..8c3158b188ef 100644
> --- a/drivers/gpu/drm/i915/display/intel_pmdemand.c
> +++ b/drivers/gpu/drm/i915/display/intel_pmdemand.c
> @@ -92,7 +92,7 @@ int intel_pmdemand_init(struct drm_i915_private *i915)
>_state->base,
>_pmdemand_funcs);
>
> - if (IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
> + if (IS_METEORLAKE_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
> /* Wa_14016740474 */
> intel_de_rmw(i915, XELPD_CHICKEN_DCPR_3, 0,
> DMD_RSP_TIMEOUT_DISABLE);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 62151abe4748..ecd4e36119b2 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1247,7 +1247,7 @@ static void wm_optimization_wa(struct intel_dp
> *intel_dp,
> bool set_wa_bit = false;
>
> /* Wa_14015648006 */
> - if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> + if (IS_METEORLAKE_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> IS_DISPLAY_VER(dev_priv, 11, 13))
> set_wa_bit |= crtc_state->wm_level_disabled;
>
> @@ -1320,7 +1320,7 @@ static void intel_psr_enable_source(struct intel_dp
> *intel_dp,
>* All supported adlp panels have 1-based X granularity, this
> may
>* cause issues if non-supported panels are used.
>*/
> - if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> + if (IS_METEORLAKE_DISPLAY_STEP(dev_priv, STEP_A0,
> STEP_B0))
> intel_de_rmw(dev_priv,
> MTL_CHICKEN_TRANS(cpu_transcoder), 0,
>ADLP_1_BASED_X_GRANULARITY);
> else if (IS_ALDERLAKE_P(dev_priv))
> @@ -1328,7 +1328,7 @@ static void intel_
Re: [Intel-gfx] [PATCH 00/11] Replace acronym with full platform name in defines.
> -Original Message- > From: Jani Nikula > Sent: Tuesday, June 20, 2023 9:31 AM > To: Bhadane, Dnyaneshwar ; intel- > g...@lists.freedesktop.org > Cc: Bhadane, Dnyaneshwar ; Srivatsa, > Anusha ; Tvrtko Ursulin > ; Joonas Lahtinen > > Subject: Re: [Intel-gfx] [PATCH 00/11] Replace acronym with full platform name > in defines. > > On Thu, 15 Jun 2023, Dnyaneshwar Bhadane > wrote: > > Replace all occurences of ADL with ALDERLAKE, TGL with TIGERLAKE, MTL > > with METEORLAKE, RKL with ROCKETLAKE, JSL with JASPERLAKE, KBL with > > KABYLAKE and SKL with SKYLAKE in platform and subplatform defines. > > This way there is a consistent pattern to how platforms are referred. > > While the change is minor and could be combined to have lesser > > patches, splitting to per subpaltform for easier cherrypicks, if > > needed. > > First of all, I'll note that changes like these need maintainer acks before > merging. > Simple review for correctness is not enough! > > While discussing this, there was perhaps a slight preference for moving > towards > acronyms for brevity instead of expanding all of them to full names. It can > get a > bit unwieldy. Yes there was. The main reason being the acronym was more brief/compact. Having said that, thinking out loud it felt having platform defines have full name would make it more clear and readable? For anyone new wanting to contribute, there will be less confusion. > > For background, the reasons for having IS__DISPLAY_STEP() are > two-fold: the steppings used to be platform specific, so it made sense to tie > platform and stepping together, and IS__DISPLAY_STEP() was > considered too long combined. > > Nowadays, we've abstracted steppings in code to be independent of platforms, > so we could use IS_() && IS_DISPLAY_STEP(), and throw out all > the IS__DISPLAY_STEP() macros. They're orthogonal things, and it actually > bugs me to have so many platform specific wrappers for the combos. > > If in addition we moved to acronyms, we could have IS_() && > IS_DISPLAY_STEP(), and it would be pretty short and nice. > > That said, all of these changes are a lot of churn, so I'd rather not make > them > lightly. Agreed. Anusha > > BR, > Jani. > > > > > > > > v2: > > - Fix the checkpatch warning. > > > > Anusha Srivatsa (5): > > drm/i915/adlp: s/ADLP/ALDERLAKE_P for display and graphics step > > drm/i915/rplp: s/ADLP/ALDERLAKE_P for RPLP defines > > drm/i915/adln: s/ADLP/ALDERLAKE_P in ADLN defines > > drm/i915/adls: s/ADLS/ALDERLAKE_S in platform and subplatform defines > > drm/i915/rplu: s/ADLP/ALDERLAKE_P in RPLU defines > > > > Dnyaneshwar Bhadane (6): > > drm/i915/TGL: s/TGL/TIGERLAKE for platform/subplatform defines > > drm/i915/MTL: s/MTL/METEORLAKE for platform/subplatform defines > > drm/i915/TGL: s/RKL/ROCKETLAKE for platform/subplatform defines > > drm/i915/JSL: s/JSL/JASPERLAKE for platform/subplatform defines > > drm/i915/KBL: s/KBL/KABYLAKE for platform/subplatform defines > > drm/i915/SKL: s/SKL/SKYLAKE for platform/subplatform defines > > > > drivers/gpu/drm/i915/display/icl_dsi.c| 4 +- > > drivers/gpu/drm/i915/display/intel_cdclk.c| 8 +-- > > .../gpu/drm/i915/display/intel_combo_phy.c| 6 +- > > drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- > > .../drm/i915/display/intel_ddi_buf_trans.c| 10 +-- > > drivers/gpu/drm/i915/display/intel_display.c | 6 +- > > .../drm/i915/display/intel_display_device.c | 2 +- > > .../drm/i915/display/intel_display_power.c| 2 +- > > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 20 +++--- > > drivers/gpu/drm/i915/display/intel_fbc.c | 2 +- > > drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- > > drivers/gpu/drm/i915/display/intel_pmdemand.c | 2 +- > > drivers/gpu/drm/i915/display/intel_psr.c | 20 +++--- > > .../drm/i915/display/skl_universal_plane.c| 10 +-- > > drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +- > > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 10 +-- > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- > > .../drm/i915/gt/intel_execlists_submission.c | 2 +- > > drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 4 +- > > drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +- > > drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +- > > drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +- > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 54 > > drive
Re: [Intel-gfx] [PATCH 04/11] drm/i915/JSL: s/JSL/JASPERLAKE for platform/subplatform defines
> -Original Message- > From: Intel-gfx On Behalf Of Jani > Nikula > Sent: Monday, June 19, 2023 1:46 AM > To: Bhadane, Dnyaneshwar ; intel- > g...@lists.freedesktop.org > Cc: Bhadane, Dnyaneshwar > Subject: Re: [Intel-gfx] [PATCH 04/11] drm/i915/JSL: s/JSL/JASPERLAKE for > platform/subplatform defines > > On Thu, 15 Jun 2023, Dnyaneshwar Bhadane > wrote: > > Follow consistent naming convention. Replace JSL with JASPERLAKE. > > > > Signed-off-by: Dnyaneshwar Bhadane > > > -#define IS_JSL_EHL(i915) (IS_PLATFORM(i915, INTEL_JASPERLAKE) || \ > > +#define IS_JASPERLAKE_EHL(i915)(IS_PLATFORM(i915, > INTEL_JASPERLAKE) || \ > > IS_PLATFORM(i915, INTEL_ELKHARTLAKE)) > > The new name for this is just dumb. This matches two platforms, JSL and EHL, > and there's no point in one of them being an acronym and the other one not. > > And IS_JASPERLAKE_ELKHARTLAKE() would be too long. > Agreed on the long name. Given that we are not touching Elkhartlake in this series, we can probably skip jasperlake too? Anusha > BR, > Jani. > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 00/11] Replace acronym with full platform name in defines.
> -Original Message- > From: Bhadane, Dnyaneshwar > Sent: Wednesday, June 14, 2023 10:00 PM > To: intel-gfx@lists.freedesktop.org > Cc: Atwood, Matthew S ; Srivatsa, Anusha > ; Bhadane, Dnyaneshwar > > Subject: [PATCH 00/11] Replace acronym with full platform name in defines. > > Replace all occurences of ADL with ALDERLAKE, TGL with TIGERLAKE, MTL with > METEORLAKE, RKL with ROCKETLAKE, JSL with JASPERLAKE, KBL with KABYLAKE > and SKL with SKYLAKE in platform and subplatform defines. This way there is a > consistent pattern to how platforms are referred. While the change is minor > and > could be combined to have lesser patches, splitting to per subpaltform for > easier > cherrypicks, if needed. Thanks for taking this forward. I have reviewed the patches with the only feedback being use of lower case in the subject prefix. But the series also needs platform reordering. It should start from oldest to newest platform. SO Patch 1:SKL Patch 2:KBL Patch 3:RKL And so on. Order being: SLK->KBL->RKL->JSL->TGL->ADLPS and its various flavours->ADLS->MTL Anusha > > Anusha Srivatsa (5): > drm/i915/adlp: s/ADLP/ALDERLAKE_P for display and graphics step > drm/i915/rplp: s/ADLP/ALDERLAKE_P for RPLP defines > drm/i915/adln: s/ADLP/ALDERLAKE_P in ADLN defines > drm/i915/adls: s/ADLS/ALDERLAKE_S in platform and subplatform defines > drm/i915/rplu: s/ADLP/ALDERLAKE_P in RPLU defines > > Dnyaneshwar Bhadane (6): > drm/i915/TGL: s/TGL/TIGERLAKE for platform/subplatform defines > drm/i915/MTL: s/MTL/METEORLAKE for platform/subplatform defines > drm/i915/TGL: s/RKL/ROCKETLAKE for platform/subplatform defines > drm/i915/JSL: s/JSL/JASPERLAKE for platform/subplatform defines > drm/i915/KBL: s/KBL/KABYLAKE for platform/subplatform defines > drm/i915/SKL: s/SKL/SKYLAKE for platform/subplatform defines > > drivers/gpu/drm/i915/display/icl_dsi.c| 4 +- > drivers/gpu/drm/i915/display/intel_cdclk.c| 8 +-- > .../gpu/drm/i915/display/intel_combo_phy.c| 6 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 6 +- > .../drm/i915/display/intel_ddi_buf_trans.c| 10 +-- > drivers/gpu/drm/i915/display/intel_display.c | 6 +- > .../drm/i915/display/intel_display_device.c | 2 +- > .../drm/i915/display/intel_display_power.c| 2 +- > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 20 +++--- > drivers/gpu/drm/i915/display/intel_fbc.c | 2 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- > drivers/gpu/drm/i915/display/intel_pmdemand.c | 2 +- > drivers/gpu/drm/i915/display/intel_psr.c | 20 +++--- > .../drm/i915/display/skl_universal_plane.c| 10 +-- > drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +- > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 10 +-- > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- > .../drm/i915/gt/intel_execlists_submission.c | 2 +- > drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 4 +- > drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +- > drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +- > drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 54 > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +- > .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +- > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +- > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +- > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +- > drivers/gpu/drm/i915/i915_drv.h | 64 +-- > drivers/gpu/drm/i915/i915_perf.c | 4 +- > drivers/gpu/drm/i915/intel_clock_gating.c | 4 +- > drivers/gpu/drm/i915/intel_step.c | 10 +-- > drivers/gpu/drm/i915/soc/intel_pch.c | 6 +- > 34 files changed, 143 insertions(+), 143 deletions(-) > > -- > 2.34.1
Re: [Intel-gfx] [PATCH 10/11] drm/i915/adls: s/ADLS/ALDERLAKE_S in platform and subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Thursday, June 15, 2023 2:54 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha
> Subject: [PATCH 10/11] drm/i915/adls: s/ADLS/ALDERLAKE_S in platform and
> subplatform defines
>
> From: Anusha Srivatsa
>
> Driver refers to the platfrom Alderlake S as ADLS in places and ALDERLAKE_S in
^^^ same typo again!
Anusha
> some. Making the consistent change to avoid confusion of the right naming
> convention for the platform.
>
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_display_device.c | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 6 +++---
> drivers/gpu/drm/i915/intel_step.c | 2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
> b/drivers/gpu/drm/i915/display/intel_display_device.c
> index 3fd30e7f0062..f3090b8afc60 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_device.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_device.c
> @@ -797,7 +797,7 @@ void intel_display_device_info_runtime_init(struct
> drm_i915_private *i915)
> enum pipe pipe;
>
> /* Wa_14011765242: adl-s A0,A1 */
> - if (IS_ADLS_DISPLAY_STEP(i915, STEP_A0, STEP_A2))
> + if (IS_ALDERLAKE_S_DISPLAY_STEP(i915, STEP_A0, STEP_A2))
> for_each_pipe(i915, pipe)
> display_runtime->num_scalers[pipe] = 0;
> else if (DISPLAY_VER(i915) >= 11) {
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index 18250fb64bd8..eb28705b88bd 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -43,7 +43,7 @@ static void uc_expand_default_options(struct intel_uc *uc)
> }
>
> /* Intermediate platforms are HuC authentication only */
> - if (IS_ALDERLAKE_S(i915) && !IS_ADLS_RPLS(i915)) {
> + if (IS_ALDERLAKE_S(i915) && !IS_ALDERLAKE_S_RPLS(i915)) {
> i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> return;
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d3ce6ed3be86..1dad0c9b4f30 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -585,7 +585,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G11)
> #define IS_DG2_G12(i915) \
> IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G12) -
> #define IS_ADLS_RPLS(i915) \
> +#define IS_ALDERLAKE_S_RPLS(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_S,
> INTEL_SUBPLATFORM_RPL) #define IS_ALDERLAKE_P_N(i915) \
> IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P,
> INTEL_SUBPLATFORM_N) @@ -669,11 +669,11 @@ IS_SUBPLATFORM(const
> struct drm_i915_private *i915, #define IS_ROCKETLAKE_DISPLAY_STEP(p, since,
> until) \
> (IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until))
>
> -#define IS_ADLS_DISPLAY_STEP(__i915, since, until) \
> +#define IS_ALDERLAKE_S_DISPLAY_STEP(__i915, since, until) \
> (IS_ALDERLAKE_S(__i915) && \
>IS_DISPLAY_STEP(__i915, since, until))
>
> -#define IS_ADLS_GRAPHICS_STEP(__i915, since, until) \
> +#define IS_ALDERLAKE_GRAPHICS_STEP(__i915, since, until) \
> (IS_ALDERLAKE_S(__i915) && \
>IS_GRAPHICS_STEP(__i915, since, until))
>
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index fe447063a064..f410aa2a8077 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -201,7 +201,7 @@ void intel_step_init(struct drm_i915_private *i915)
> } else if (IS_ALDERLAKE_P(i915)) {
> revids = adlp_revids;
> size = ARRAY_SIZE(adlp_revids);
> - } else if (IS_ADLS_RPLS(i915)) {
> + } else if (IS_ALDERLAKE_S_RPLS(i915)) {
> revids = adls_rpls_revids;
> size = ARRAY_SIZE(adls_rpls_revids);
> } else if (IS_ALDERLAKE_S(i915)) {
> --
> 2.34.1
Re: [Intel-gfx] [PATCH 07/11] drm/i915/adlp: s/ADLP/ALDERLAKE_P for display and graphics step
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, June 14, 2023 10:00 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Atwood, Matthew S ; Srivatsa, Anusha
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH 07/11] drm/i915/adlp: s/ADLP/ALDERLAKE_P for display and
> graphics step
>
> From: Anusha Srivatsa
>
> Driver refers to the platfrom Alderlake P as ADLP in places and ALDERLAKE_P in
^^^ noyiced I have made a typo @Bhadane, Dnyaneshwar
You can fix the typo and add you S-O-B too with mine in the next spin.
Anusha
> some. Making the consistent change to avoid confusion of the right naming
> convention for the platform.
>
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 8
> drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 ++--
> drivers/gpu/drm/i915/i915_drv.h| 4 ++--
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 2acfa0435675..831d1258ea3f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -3559,7 +3559,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> dev_priv->display.cdclk.table = dg2_cdclk_table;
> } else if (IS_ALDERLAKE_P(dev_priv)) {
> /* Wa_22011320316:adl-p[a0] */
> - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> + if (IS_ALDERLAKE_P_DISPLAY_STEP(dev_priv, STEP_A0,
> STEP_B0))
> dev_priv->display.cdclk.table =
> adlp_a_step_cdclk_table;
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> } else if (IS_ADLP_RPLU(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index c6d376d414b8..47fe8311067e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -3781,7 +3781,7 @@ static void adlp_cmtg_clock_gating_wa(struct
> drm_i915_private *i915, struct inte {
> u32 val;
>
> - if (!IS_ADLP_DISPLAY_STEP(i915, STEP_A0, STEP_B0) ||
> + if (!IS_ALDERLAKE_P_DISPLAY_STEP(i915, STEP_A0, STEP_B0) ||
> pll->info->id != DPLL_ID_ICL_DPLL0)
> return;
> /*
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index f61d39d2b0fc..00c98c2b4324 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -639,7 +639,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> }
>
> /* Wa_22012278275:adl-p */
> - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_E0)) {
> + if (IS_ALDERLAKE_P_DISPLAY_STEP(dev_priv, STEP_A0, STEP_E0)) {
> static const u8 map[] = {
> 2, /* 5 lines */
> 1, /* 6 lines */
> @@ -807,7 +807,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp
> *intel_dp,
> return;
>
> /* Wa_16011303918:adl-p */
> - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> + if (IS_ALDERLAKE_P_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> return;
>
> /*
> @@ -975,7 +975,7 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> return false;
> }
>
> - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> + if (IS_ALDERLAKE_P_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> drm_dbg_kms(_priv->drm, "PSR2 not completely
> functional in this stepping\n");
> return false;
> }
> @@ -1033,7 +1033,7 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
>
> /* Wa_16011303918:adl-p */
> if (crtc_state->vrr.enable &&
> - IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> + IS_ALDERLAKE_P_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
> drm_dbg_kms(_priv->drm,
> "PSR2 not enabled, not compatible with HW stepping
> + VRR\n");
> return false;
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 25b06ced9ce7..2458a9ea25ba 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_un
Re: [Intel-gfx] [PATCH 06/11] drm/i915/SKL: s/SKL/SKYLAKE for platform/subplatform defines
Apart from the platform subject prefix,
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, June 14, 2023 10:00 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Atwood, Matthew S ; Srivatsa, Anusha
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH 06/11] drm/i915/SKL: s/SKL/SKYLAKE for platform/subplatform
> defines
>
> Follow consistent naming convention. Replace SKL with SKYLAKE.
>
> Signed-off-by: Dnyaneshwar Bhadane
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 14 +++---
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index 84b09d188d2a..ab84d003232c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1724,9 +1724,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder
> *encoder)
> encoder->get_buf_trans = kbl_u_get_buf_trans;
> } else if (IS_COMETLAKE(i915) || IS_COFFEELAKE(i915) ||
> IS_KABYLAKE(i915)) {
> encoder->get_buf_trans = kbl_get_buf_trans;
> - } else if (IS_SKL_ULX(i915)) {
> + } else if (IS_SKYLAKE_ULX(i915)) {
> encoder->get_buf_trans = skl_y_get_buf_trans;
> - } else if (IS_SKL_ULT(i915)) {
> + } else if (IS_SKYLAKE_ULT(i915)) {
> encoder->get_buf_trans = skl_u_get_buf_trans;
> } else if (IS_SKYLAKE(i915)) {
> encoder->get_buf_trans = skl_get_buf_trans; diff --git
> a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index b632fb5592a8..10a4e0fc23ec 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1173,7 +1173,7 @@ skl_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
>
> /* WaInPlaceDecompressionHang:skl */
> - if (IS_SKL_GRAPHICS_STEP(gt->i915, STEP_A0, STEP_H0))
> + if (IS_SKYLAKE_GRAPHICS_STEP(gt->i915, STEP_A0, STEP_H0))
> wa_write_or(wal,
> GEN9_GAMT_ECO_REG_RW_IA,
> GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f19915115cff..3c4a66f1a7ba 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -610,19 +610,19 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> /* ULX machines are also considered ULT. */ #define IS_HSW_ULX(i915) \
> IS_SUBPLATFORM(i915, INTEL_HASWELL, INTEL_SUBPLATFORM_ULX) -
> #define IS_SKL_ULT(i915) \
> +#define IS_SKYLAKE_ULT(i915) \
> IS_SUBPLATFORM(i915, INTEL_SKYLAKE, INTEL_SUBPLATFORM_ULT) -
> #define IS_SKL_ULX(i915) \
> +#define IS_SKYLAKE_ULX(i915) \
> IS_SUBPLATFORM(i915, INTEL_SKYLAKE, INTEL_SUBPLATFORM_ULX)
> #define IS_KABYLAKE_ULT(i915) \
> IS_SUBPLATFORM(i915, INTEL_KABYLAKE, INTEL_SUBPLATFORM_ULT)
> #define IS_KABYLAKE_ULX(i915) \
> IS_SUBPLATFORM(i915, INTEL_KABYLAKE, INTEL_SUBPLATFORM_ULX)
> -#define IS_SKL_GT2(i915) (IS_SKYLAKE(i915) && \
> +#define IS_SKYLAKE_GT2(i915) (IS_SKYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 2)
> -#define IS_SKL_GT3(i915) (IS_SKYLAKE(i915) && \
> +#define IS_SKYLAKE_GT3(i915) (IS_SKYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 3)
> -#define IS_SKL_GT4(i915) (IS_SKYLAKE(i915) && \
> +#define IS_SKYLAKE_GT4(i915) (IS_SKYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 4)
> #define IS_KABYLAKE_GT2(i915)(IS_KABYLAKE(i915) && \
>INTEL_INFO(i915)->gt == 2)
> @@ -650,7 +650,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_TIGERLAKE_UY(i915) \
> IS_SUBPLATFORM(i915, INTEL_TIGERLAKE, INTEL_SUBPLATFORM_UY)
>
> -#define IS_SKL_GRAPHICS_STEP(p, since, until) (IS_SKYLAKE(p) &&
> IS_GRAPHICS_STEP(p, since, until))
> +#define IS_SKYLAKE_GRAPHICS_STEP(p, since, until) (IS_SKYLAKE(p) &&
> +IS_GRAPHICS_STEP(p, since, until))
>
> #define IS_KABYLAKE_GRAPHICS_STEP(i915, since, until) \
> (IS_KABYLAKE(i915) && IS_GRAPHICS_STEP(i915, since, until)) @@ -
> 801,7 +801,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>
> /* WaRsDisableCoarsePowerGating:skl,cnl */
> #define NEEDS_WaRsDisableCoarsePowerGating(i915) \
> - (IS_SKL_GT3(i915) || IS_SKL_GT4(i915))
> + (IS_SKYLAKE_GT3(i915) || IS_SKYLAKE_GT4(i915))
>
> /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
> * rows, which changed the alignment requirements and fence programming.
> --
> 2.34.1
Re: [Intel-gfx] [PATCH 05/11] drm/i915/KBL: s/KBL/KABYLAKE for platform/subplatform defines
OK one thing that holds true for all patches in the series is the subject:
drm/i915/PLATFORM:
The general convention is to have platform is lower cases I the subject prefix.
So all occurrences of drm/i915/PLATFORM should be replaced with
drm/i915/platform.
This is something I have missed mentioning in the previous patches that gave a
r-b to.
Apart from the above mentioned platform prefix feedback,
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, June 14, 2023 10:00 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Atwood, Matthew S ; Srivatsa, Anusha
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH 05/11] drm/i915/KBL: s/KBL/KABYLAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace KBL with KABYLAKE.
>
> Signed-off-by: Dnyaneshwar Bhadane
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 4 ++--
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c| 6 +++---
> drivers/gpu/drm/i915/i915_drv.h| 12 ++--
> drivers/gpu/drm/i915/intel_clock_gating.c | 4 ++--
> 5 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index 9e34cc103aeb..84b09d188d2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1718,9 +1718,9 @@ void intel_ddi_buf_trans_init(struct intel_encoder
> *encoder)
> encoder->get_buf_trans = icl_get_mg_buf_trans;
> } else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
> encoder->get_buf_trans = bxt_get_buf_trans;
> - } else if (IS_CML_ULX(i915) || IS_CFL_ULX(i915) || IS_KBL_ULX(i915)) {
> + } else if (IS_CML_ULX(i915) || IS_CFL_ULX(i915) ||
> +IS_KABYLAKE_ULX(i915)) {
> encoder->get_buf_trans = kbl_y_get_buf_trans;
> - } else if (IS_CML_ULT(i915) || IS_CFL_ULT(i915) || IS_KBL_ULT(i915)) {
> + } else if (IS_CML_ULT(i915) || IS_CFL_ULT(i915) ||
> +IS_KABYLAKE_ULT(i915)) {
> encoder->get_buf_trans = kbl_u_get_buf_trans;
> } else if (IS_COMETLAKE(i915) || IS_COFFEELAKE(i915) ||
> IS_KABYLAKE(i915)) {
> encoder->get_buf_trans = kbl_get_buf_trans; diff --git
> a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index eb72610a8588..ec0771dc662a 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -43,7 +43,7 @@ int gen8_emit_flush_rcs(struct i915_request *rq, u32
> mode)
> vf_flush_wa = true;
>
> /* WaForGAMHang:kbl */
> - if (IS_KBL_GRAPHICS_STEP(rq->engine->i915, 0, STEP_C0))
> + if (IS_KABYLAKE_GRAPHICS_STEP(rq->engine->i915, 0,
> STEP_C0))
> dc_flush_wa = true;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a62dcbc2f901..b632fb5592a8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -584,7 +584,7 @@ static void kbl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> gen9_ctx_workarounds_init(engine, wal);
>
> /* WaToEnableHwFixForPushConstHWBug:kbl */
> - if (IS_KBL_GRAPHICS_STEP(i915, STEP_C0, STEP_FOREVER))
> + if (IS_KABYLAKE_GRAPHICS_STEP(i915, STEP_C0, STEP_FOREVER))
> wa_masked_en(wal, COMMON_SLICE_CHICKEN2,
>GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
>
> @@ -1185,7 +1185,7 @@ kbl_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> gen9_gt_workarounds_init(gt, wal);
>
> /* WaDisableDynamicCreditSharing:kbl */
> - if (IS_KBL_GRAPHICS_STEP(gt->i915, 0, STEP_C0))
> + if (IS_KABYLAKE_GRAPHICS_STEP(gt->i915, 0, STEP_C0))
> wa_write_or(wal,
> GAMT_CHKN_BIT_REG,
>
> GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING);
> @@ -2933,7 +2933,7 @@ xcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> struct drm_i915_private *i915 = engine->i915;
>
> /* WaKBLVECSSemaphoreWaitPoll:kbl */
> - if (IS_KBL_GRAPHICS_STEP(i915, STEP_A0, STEP_F0)) {
> + if (IS_KABYLAKE_GRAPHICS_STEP(i915, STEP_A0, STEP_F0)) {
> wa_write(wal,
>RING_SEMA_WAIT_POLL(engine->mmio_base),
>1);
> diff --git a/drivers/gpu/drm/i915/i915_drv.
Re: [Intel-gfx] [PATCH 04/11] drm/i915/JSL: s/JSL/JASPERLAKE for platform/subplatform defines
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, June 14, 2023 10:00 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Atwood, Matthew S ; Srivatsa, Anusha
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH 04/11] drm/i915/JSL: s/JSL/JASPERLAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace JSL with JASPERLAKE.
>
> Signed-off-by: Dnyaneshwar Bhadane
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_ddi.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 18 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 10 +-
> drivers/gpu/drm/i915/intel_step.c | 2 +-
> drivers/gpu/drm/i915/soc/intel_pch.c | 6 +++---
> 15 files changed, 37 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 59a2a289d9be..70f045da3bac 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -444,7 +444,7 @@ static void
> gen11_dsi_config_phy_lanes_sequence(struct intel_encoder *encoder)
> intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
>
> /* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
> - if (IS_JSL_EHL(dev_priv) || (DISPLAY_VER(dev_priv) >= 12)) {
> + if (IS_JASPERLAKE_EHL(dev_priv) || (DISPLAY_VER(dev_priv) >=
> 12)) {
> intel_de_rmw(dev_priv,
> ICL_PORT_PCS_DW1_AUX(phy),
>LATENCY_OPTIM_MASK,
> LATENCY_OPTIM_VAL(0));
>
> @@ -553,7 +553,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder
> *encoder,
> }
> }
>
> - if (IS_JSL_EHL(dev_priv)) {
> + if (IS_JASPERLAKE_EHL(dev_priv)) {
> for_each_dsi_phy(phy, intel_dsi->phys)
> intel_de_rmw(dev_priv, ICL_DPHY_CHKN(phy),
>0, ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP);
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 4207863b7b2a..2acfa0435675 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -3147,7 +3147,7 @@ static int intel_compute_max_dotclk(struct
> drm_i915_private *dev_priv)
> */
> void intel_update_max_cdclk(struct drm_i915_private *dev_priv) {
> - if (IS_JSL_EHL(dev_priv)) {
> + if (IS_JASPERLAKE_EHL(dev_priv)) {
> if (dev_priv->display.cdclk.hw.ref == 24000)
> dev_priv->display.cdclk.max_cdclk_freq = 552000;
> else
> @@ -3575,7 +3575,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> } else if (DISPLAY_VER(dev_priv) >= 12) {
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> dev_priv->display.cdclk.table = icl_cdclk_table;
> - } else if (IS_JSL_EHL(dev_priv)) {
> + } else if (IS_JASPERLAKE_EHL(dev_priv)) {
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> dev_priv->display.cdclk.table = icl_cdclk_table;
> } else if (DISPLAY_VER(dev_priv) >= 11) { diff --git
> a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 922a6d87b553..37bd6d31ced1 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -141,7 +141,7 @@ static bool has_phy_misc(struct drm_i915_private
> *i915, enum phy phy)
>
> if (IS_ALDERLAKE_S(i915))
> return phy == PHY_A;
> - else if (IS_JSL_EHL(i915) ||
> + else if (IS_JASPERLAKE_EHL(i915) ||
>IS_ROCKETLAKE(i915) ||
>IS_DG1(i915))
> return phy < PHY_C;
> @@ -242,7 +242,7 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
> ret &= check_phy_reg(dev_priv, phy,
> ICL_PORT_COMP_DW8(phy),
>
Re: [Intel-gfx] [PATCH 03/11] drm/i915/TGL: s/RKL/ROCKETLAKE for platform/subplatform defines
Reviewed-by: Anusha Srivatsa > -Original Message- > From: Bhadane, Dnyaneshwar > Sent: Wednesday, June 14, 2023 10:00 PM > To: intel-gfx@lists.freedesktop.org > Cc: Atwood, Matthew S ; Srivatsa, Anusha > ; Bhadane, Dnyaneshwar > > Subject: [PATCH 03/11] drm/i915/TGL: s/RKL/ROCKETLAKE for > platform/subplatform defines > > Follow consistent naming convention. Replace RKL with ROCKETLAKE. > > Signed-off-by: Dnyaneshwar Bhadane > --- > drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- > drivers/gpu/drm/i915/i915_drv.h| 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > b/drivers/gpu/drm/i915/display/intel_display_power.c > index db5437043904..c65505b82065 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > @@ -1586,7 +1586,7 @@ static void tgl_bw_buddy_init(struct > drm_i915_private *dev_priv) > return; > > if (IS_ALDERLAKE_S(dev_priv) || > - IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > + IS_ROCKETLAKE_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) > /* Wa_1409767108 */ > table = wa_1409767108_buddy_page_masks; > else > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 472a36cf1a72..3e9567f9ad15 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -666,7 +666,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > (IS_TIGERLAKE(__i915) && \ >IS_DISPLAY_STEP(__i915, since, until)) > > -#define IS_RKL_DISPLAY_STEP(p, since, until) \ > +#define IS_ROCKETLAKE_DISPLAY_STEP(p, since, until) \ > (IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until)) > > #define IS_ADLS_DISPLAY_STEP(__i915, since, until) \ > -- > 2.34.1
Re: [Intel-gfx] [PATCH 02/11] drm/i915/MTL: s/MTL/METEORLAKE for platform/subplatform defines
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, June 14, 2023 10:00 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Atwood, Matthew S ; Srivatsa, Anusha
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH 02/11] drm/i915/MTL: s/MTL/METEORLAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace MTL with METEORLAKE
>
> Signed-off-by: Dnyaneshwar Bhadane
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_pmdemand.c | 2 +-
> drivers/gpu/drm/i915/display/intel_psr.c | 10 ++---
> .../drm/i915/display/skl_universal_plane.c| 4 +-
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 8 ++--
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> .../drm/i915/gt/intel_execlists_submission.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 4 +-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 44 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +-
> drivers/gpu/drm/i915/i915_drv.h | 6 +--
> drivers/gpu/drm/i915/i915_perf.c | 4 +-
> 15 files changed, 51 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 7f8b2d7713c7..6358a8b26172 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1093,7 +1093,7 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
>
> /* Wa_14016291713 */
> if ((IS_DISPLAY_VER(i915, 12, 13) ||
> - IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
> + IS_METEORLAKE_DISPLAY_STEP(i915, STEP_A0, STEP_C0)) &&
> crtc_state->has_psr) {
> plane_state->no_fbc_reason = "PSR1 enabled
> (Wa_14016291713)";
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_pmdemand.c
> b/drivers/gpu/drm/i915/display/intel_pmdemand.c
> index f7608d363634..8c3158b188ef 100644
> --- a/drivers/gpu/drm/i915/display/intel_pmdemand.c
> +++ b/drivers/gpu/drm/i915/display/intel_pmdemand.c
> @@ -92,7 +92,7 @@ int intel_pmdemand_init(struct drm_i915_private *i915)
>_state->base,
>_pmdemand_funcs);
>
> - if (IS_MTL_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
> + if (IS_METEORLAKE_DISPLAY_STEP(i915, STEP_A0, STEP_C0))
> /* Wa_14016740474 */
> intel_de_rmw(i915, XELPD_CHICKEN_DCPR_3, 0,
> DMD_RSP_TIMEOUT_DISABLE);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index d58ed9b62e67..06b464229efe 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1247,7 +1247,7 @@ static void wm_optimization_wa(struct intel_dp
> *intel_dp,
> bool set_wa_bit = false;
>
> /* Wa_14015648006 */
> - if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> + if (IS_METEORLAKE_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> IS_DISPLAY_VER(dev_priv, 11, 13))
> set_wa_bit |= crtc_state->wm_level_disabled;
>
> @@ -1320,7 +1320,7 @@ static void intel_psr_enable_source(struct intel_dp
> *intel_dp,
>* All supported adlp panels have 1-based X granularity, this
> may
>* cause issues if non-supported panels are used.
>*/
> - if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> + if (IS_METEORLAKE_DISPLAY_STEP(dev_priv, STEP_A0,
> STEP_B0))
> intel_de_rmw(dev_priv,
> MTL_CHICKEN_TRANS(cpu_transcoder), 0,
>ADLP_1_BASED_X_GRANULARITY);
> else if (IS_ALDERLAKE_P(dev_priv))
> @@ -1328,7 +1328,7 @@ static void intel_psr_enable_source(struct intel_dp
> *intel_dp,
>ADLP_1_BASED_X_GRANULARITY);
>
> /* Wa_16012604467:adlp,mtl[a0,b0] */
> - if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> + if (IS_METEORLAKE_DISPLAY_STEP(dev_priv, STEP_A0,
> STEP_B0))
> intel_de_rmw(dev_priv,
>MTL_CLKGATE_DIS_TRANS(cpu_transcoder),
> 0,
>
> MTL_CLKGATE_DIS_TRANS_DMASC_GATING_DIS);
> @@ -1489,7 +1489,7 @@ static void intel_psr_disable_locked(struct intel_dp
> *intel_dp)
>
>
Re: [Intel-gfx] [PATCH 01/11] drm/i915/TGL: s/TGL/TIGERLAKE for platform/subplatform defines
> -Original Message-
> From: Bhadane, Dnyaneshwar
> Sent: Wednesday, June 14, 2023 10:00 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Atwood, Matthew S ; Srivatsa, Anusha
> ; Bhadane, Dnyaneshwar
>
> Subject: [PATCH 01/11] drm/i915/TGL: s/TGL/TIGERLAKE for
> platform/subplatform defines
>
> Follow consistent naming convention. Replace TGL with TIGERLAKE.
>
Reviewed-by: Anusha Srivatsa
> Signed-off-by: Dnyaneshwar Bhadane
> ---
> drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c | 2 +-
> drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 4 ++--
> drivers/gpu/drm/i915/intel_step.c | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index b7d20485bde5..9e34cc103aeb 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1390,7 +1390,7 @@ tgl_get_combo_buf_trans_dp(struct intel_encoder
> *encoder,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>
> if (crtc_state->port_clock > 27) {
> - if (IS_TGL_UY(dev_priv)) {
> + if (IS_TIGERLAKE_UY(dev_priv)) {
> return
> intel_get_buf_trans(_uy_combo_phy_trans_dp_hbr2,
> n_entries);
> } else {
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 6b01a0b68b97..26def9cb86e4 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -2196,7 +2196,7 @@ static bool gen12_plane_has_mc_ccs(struct
> drm_i915_private *i915,
>
> /* Wa_14010477008 */
> if (IS_DG1(i915) || IS_ROCKETLAKE(i915) ||
> - IS_TGL_DISPLAY_STEP(i915, STEP_A0, STEP_D0))
> + IS_TIGERLAKE_DISPLAY_STEP(i915, STEP_A0, STEP_D0))
> return false;
>
> /* Wa_22011186057 */
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b4cf6f0f636d..0f30dc890209 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -647,7 +647,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_ICL_WITH_PORT_F(i915) \
> IS_SUBPLATFORM(i915, INTEL_ICELAKE, INTEL_SUBPLATFORM_PORTF)
>
> -#define IS_TGL_UY(i915) \
> +#define IS_TIGERLAKE_UY(i915) \
> IS_SUBPLATFORM(i915, INTEL_TIGERLAKE, INTEL_SUBPLATFORM_UY)
>
> #define IS_SKL_GRAPHICS_STEP(p, since, until) (IS_SKYLAKE(p) &&
> IS_GRAPHICS_STEP(p, since, until)) @@ -662,7 +662,7 @@
> IS_SUBPLATFORM(const struct drm_i915_private *i915, #define
> IS_JSL_EHL_DISPLAY_STEP(p, since, until) \
> (IS_JSL_EHL(p) && IS_DISPLAY_STEP(p, since, until))
>
> -#define IS_TGL_DISPLAY_STEP(__i915, since, until) \
> +#define IS_TIGERLAKE_DISPLAY_STEP(__i915, since, until) \
> (IS_TIGERLAKE(__i915) && \
>IS_DISPLAY_STEP(__i915, since, until))
>
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index 8a9ff6227e53..67054c87bb5f 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -213,7 +213,7 @@ void intel_step_init(struct drm_i915_private *i915)
> } else if (IS_ROCKETLAKE(i915)) {
> revids = rkl_revids;
> size = ARRAY_SIZE(rkl_revids);
> - } else if (IS_TGL_UY(i915)) {
> + } else if (IS_TIGERLAKE_UY(i915)) {
> revids = tgl_uy_revids;
> size = ARRAY_SIZE(tgl_uy_revids);
> } else if (IS_TIGERLAKE(i915)) {
> --
> 2.34.1
Re: [Intel-gfx] [PATCH 1/5] drm/i915/adlp: s/ADLP/ALDERLAKE_P for display and graphics step
+Tvrtko +Joonas > -Original Message- > From: Jani Nikula > Sent: Monday, June 5, 2023 11:29 AM > To: Srivatsa, Anusha ; intel- > g...@lists.freedesktop.org > Subject: RE: [Intel-gfx] [PATCH 1/5] drm/i915/adlp: s/ADLP/ALDERLAKE_P for > display and graphics step > > On Mon, 05 Jun 2023, "Srivatsa, Anusha" wrote: > >> -Original Message- > >> From: Jani Nikula > >> Sent: Monday, June 5, 2023 8:14 AM > >> To: Srivatsa, Anusha ; intel- > >> g...@lists.freedesktop.org > >> Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915/adlp: > >> s/ADLP/ALDERLAKE_P for display and graphics step > >> > >> On Tue, 30 May 2023, Anusha Srivatsa wrote: > >> > Driver refers to the platfrom Alderlake P as ADLP in places and > >> > ALDERLAKE_P in some. Making the consistent change to avoid > >> > confusion of the right naming convention for the platform. > >> > >> $ git grep "#define IS_.*_DISPLAY_STEP" -- > >> drivers/gpu/drm/i915/i915_drv.h > >> drivers/gpu/drm/i915/i915_drv.h:#define IS_KBL_DISPLAY_STEP(i915, > >> since, > >> until) \ drivers/gpu/drm/i915/i915_drv.h:#define > >> IS_JSL_EHL_DISPLAY_STEP(p, since, until) \ > >> drivers/gpu/drm/i915/i915_drv.h:#define > >> IS_TGL_DISPLAY_STEP(__i915, since, until) \ > >> drivers/gpu/drm/i915/i915_drv.h:#define IS_RKL_DISPLAY_STEP(p, since, > >> until) \ drivers/gpu/drm/i915/i915_drv.h:#define > >> IS_ADLS_DISPLAY_STEP(__i915, since, > >> until) \ drivers/gpu/drm/i915/i915_drv.h:#define > >> IS_ADLP_DISPLAY_STEP(__i915, since, until) \ > >> drivers/gpu/drm/i915/i915_drv.h:#define IS_MTL_DISPLAY_STEP(__i915, > >> since, > >> until) \ drivers/gpu/drm/i915/i915_drv.h:#define > >> IS_DG2_DISPLAY_STEP(__i915, since, until) \ > >> > >> They all use the acronym. Do you suggest to rename all of them, or just > >> ADL- > P? > > > > Got the idea after looking at subplatform defines in i915_drv.h: > > > > #define IS_METEORLAKE_M(i915) \ > > IS_SUBPLATFORM(i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_M) > > #define IS_METEORLAKE_P(i915) \ > > IS_SUBPLATFORM(i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_P) > > #define IS_DG2_G10(i915) \ > > IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G10) #define > > IS_DG2_G11(i915) \ > > IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G11) #define > > IS_DG2_G12(i915) \ > > IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G12) #define > > IS_ADLS_RPLS(i915) \ > > IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_S, > INTEL_SUBPLATFORM_RPL) > > #define IS_ADLP_N(i915) \ > > IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P, INTEL_SUBPLATFORM_N) > > #define IS_ADLP_RPLP(i915) \ > > IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P, > INTEL_SUBPLATFORM_RPL) > > #define IS_ADLP_RPLU(i915) \ > > IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P, > > INTEL_SUBPLATFORM_RPLU) > > > > We are using the same platform name for platform and sub-platform defines > for Meteor Lake and DG2, but somehow for flavors of Alder Lake, the sub- > platform has acronym. The idea was that developers should not think if the > full > name or acronym has to be used. And that resulted in the series. But now that > you have pointed out the above other such occurrences, I am leaning towards > having them changed as well. That is for a platform defined as TIGERLAKE, All > of > its steppings etc should have > TIGERLAKE_(TIGERLAKE_MEDIA_,TIGERLAKE_DISPLAY_, TIGERLAKE_GRAPHICS_ > ) etc instead of having TIGERLAKE in some places and TGL in its stepping or > sub- > platform defines. > > > > This was the naming is uniform and consistent. > > One could also make the case for switching all of them use the acronym instead > for brevity. That works too. Anusha > BR, > Jani. > > > > > > Anusha > >> BR, > >> Jani. > >> > >> > >> > >> > > >> > Signed-off-by: Anusha Srivatsa > >> > --- > >> > drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +- > >> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- > >> > drivers/gpu/drm/i915/display/intel_psr.c | 8 > >> > drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 ++-- > >> > drivers/gpu/drm/i915/i915_drv.h| 4 ++-- > >> > 5 files changed, 10 insertions(+), 10 deletions(-) > >> > > >>
Re: [Intel-gfx] [PATCH 1/5] drm/i915/adlp: s/ADLP/ALDERLAKE_P for display and graphics step
> -Original Message-
> From: Jani Nikula
> Sent: Monday, June 5, 2023 8:14 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915/adlp: s/ADLP/ALDERLAKE_P for
> display and graphics step
>
> On Tue, 30 May 2023, Anusha Srivatsa wrote:
> > Driver refers to the platfrom Alderlake P as ADLP in places and
> > ALDERLAKE_P in some. Making the consistent change to avoid confusion
> > of the right naming convention for the platform.
>
> $ git grep "#define IS_.*_DISPLAY_STEP" -- drivers/gpu/drm/i915/i915_drv.h
> drivers/gpu/drm/i915/i915_drv.h:#define IS_KBL_DISPLAY_STEP(i915, since,
> until) \ drivers/gpu/drm/i915/i915_drv.h:#define IS_JSL_EHL_DISPLAY_STEP(p,
> since, until) \ drivers/gpu/drm/i915/i915_drv.h:#define
> IS_TGL_DISPLAY_STEP(__i915, since, until) \
> drivers/gpu/drm/i915/i915_drv.h:#define IS_RKL_DISPLAY_STEP(p, since, until) \
> drivers/gpu/drm/i915/i915_drv.h:#define IS_ADLS_DISPLAY_STEP(__i915, since,
> until) \ drivers/gpu/drm/i915/i915_drv.h:#define
> IS_ADLP_DISPLAY_STEP(__i915, since, until) \
> drivers/gpu/drm/i915/i915_drv.h:#define IS_MTL_DISPLAY_STEP(__i915, since,
> until) \ drivers/gpu/drm/i915/i915_drv.h:#define IS_DG2_DISPLAY_STEP(__i915,
> since, until) \
>
> They all use the acronym. Do you suggest to rename all of them, or just ADL-P?
Got the idea after looking at subplatform defines in i915_drv.h:
#define IS_METEORLAKE_M(i915) \
IS_SUBPLATFORM(i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_M)
#define IS_METEORLAKE_P(i915) \
IS_SUBPLATFORM(i915, INTEL_METEORLAKE, INTEL_SUBPLATFORM_P)
#define IS_DG2_G10(i915) \
IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G10)
#define IS_DG2_G11(i915) \
IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G11)
#define IS_DG2_G12(i915) \
IS_SUBPLATFORM(i915, INTEL_DG2, INTEL_SUBPLATFORM_G12)
#define IS_ADLS_RPLS(i915) \
IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_S, INTEL_SUBPLATFORM_RPL)
#define IS_ADLP_N(i915) \
IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P, INTEL_SUBPLATFORM_N)
#define IS_ADLP_RPLP(i915) \
IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P, INTEL_SUBPLATFORM_RPL)
#define IS_ADLP_RPLU(i915) \
IS_SUBPLATFORM(i915, INTEL_ALDERLAKE_P, INTEL_SUBPLATFORM_RPLU)
We are using the same platform name for platform and sub-platform defines for
Meteor Lake and DG2, but somehow for flavors of Alder Lake, the sub-platform
has acronym. The idea was that developers should not think if the full name or
acronym has to be used. And that resulted in the series. But now that you have
pointed out the above other such occurrences, I am leaning towards having them
changed as well. That is for a platform defined as TIGERLAKE, All of its
steppings etc should have TIGERLAKE_(TIGERLAKE_MEDIA_,TIGERLAKE_DISPLAY_,
TIGERLAKE_GRAPHICS_ ) etc instead of having TIGERLAKE in some places and TGL
in its stepping or sub-platform defines.
This was the naming is uniform and consistent.
Anusha
> BR,
> Jani.
>
>
>
> >
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_psr.c | 8
> > drivers/gpu/drm/i915/display/skl_universal_plane.c | 4 ++--
> > drivers/gpu/drm/i915/i915_drv.h| 4 ++--
> > 5 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 6bed75f1541a..013678caaca8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -3541,7 +3541,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> > } else if (IS_ALDERLAKE_P(dev_priv)) {
> > dev_priv->display.funcs.cdclk = _cdclk_funcs;
> > /* Wa_22011320316:adl-p[a0] */
> > - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> > + if (IS_ALDERLAKE_P_DISPLAY_STEP(dev_priv, STEP_A0,
> STEP_B0))
> > dev_priv->display.cdclk.table =
> adlp_a_step_cdclk_table;
> > else if (IS_ADLP_RPLU(dev_priv))
> > dev_priv->display.cdclk.table = rplu_cdclk_table; diff
> > --
> git
> > a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > index 6b2d8a1e2aa9..81f3ce5a0a1e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> > @@ -3781,7 +3781,7 @@ static void adlp_cmtg_clock_gating_w
Re: [Intel-gfx] [PATCH] drm/i915: Implement workaround for CDCLK PLL disable/enable
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Monday, January 30, 2023 5:59 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lisovskiy, Stanislav ; Saarinen, Jani
> ; Srivatsa, Anusha
> Subject: [PATCH] drm/i915: Implement workaround for CDCLK PLL
> disable/enable
>
> It was reported that we might get a hung and loss of register access in some
> cases when CDCLK PLL is disabled and then enabled, while squashing is enabled.
> As a workaround it was proposed by HW team that SW should disable squashing
> when CDCLK PLL is being reenabled.
>
> v2: - Added WA number comment(Rodrigo Vivi)
>
> Signed-off-by: Stanislav Lisovskiy
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 7e16b655c833..8ae2b4c81f31 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1801,6 +1801,13 @@ static bool
> cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private *i91
> return true;
> }
>
> +static bool pll_enable_wa_needed(struct drm_i915_private *dev_priv) {
> + return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
> + && dev_priv->display.cdclk.hw.vco > 0
> + && HAS_CDCLK_SQUASH(dev_priv));
> +}
> +
> static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
> const struct intel_cdclk_config *cdclk_config,
> enum pipe pipe)
> @@ -1815,9 +1822,13 @@ static void _bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> !cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
> if (dev_priv->display.cdclk.hw.vco != vco)
> adlp_cdclk_pll_crawl(dev_priv, vco);
> - } else if (DISPLAY_VER(dev_priv) >= 11)
> + } else if (DISPLAY_VER(dev_priv) >= 11) {
> + /* wa_15010685871: dg2, mtl */
> + if (pll_enable_wa_needed(dev_priv))
> + dg2_cdclk_squash_program(dev_priv, 0);
> +
> icl_cdclk_pll_update(dev_priv, vco);
> - else
> + } else
> bxt_cdclk_pll_update(dev_priv, vco);
>
> waveform = cdclk_squash_waveform(dev_priv, cdclk);
> --
> 2.37.3
Re: [Intel-gfx] [PATCH v2 3/8] drm/i915: Convert pll macros to _PICK_EVEN_2RANGES
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 3/8] drm/i915: Convert pll macros to
> _PICK_EVEN_2RANGES
>
> Avoid the array lookup, converting the PLL macros after ICL to
> _PICK_EVEN_RANGES. This provides the following reduction in code size:
>
> $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new}
> textdata bss dec hex filename
> 4027456 1857036984 4220143 4064ef
> build64/drivers/gpu/drm/i915/i915.o.old
> 4026997 1857036984 4219684 406324
> build64/drivers/gpu/drm/i915/i915.o.new
>
> At the same time it's safer, avoiding out-of-bounds array access. This
> allows to
> remove _MMIO_PLL3() that is now unused.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Anusha Srivatsa
> ---
> .../drm/i915/display/intel_display_reg_defs.h | 1 -
> drivers/gpu/drm/i915/i915_reg.h | 59 +--
> 2 files changed, 29 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> index 02605418ff08..a4ed1c530799 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> @@ -34,7 +34,6 @@
> #define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
> -#define _MMIO_PLL3(pll, ...) _MMIO(_PICK(pll, __VA_ARGS__))
>
> /*
> * Device info offset array based helpers for groups of registers with
> unevenly
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8da3546d82fb..dd1eb8b10e0e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7232,13 +7232,15 @@ enum skl_power_gate {
> #define PLL_LOCK REG_BIT(30)
> #define PLL_POWER_ENABLE REG_BIT(27)
> #define PLL_POWER_STATEREG_BIT(26)
> -#define ICL_DPLL_ENABLE(pll) _MMIO_PLL3(pll, _DPLL0_ENABLE,
> _DPLL1_ENABLE, \
> -_ADLS_DPLL2_ENABLE,
> _ADLS_DPLL3_ENABLE)
> +#define ICL_DPLL_ENABLE(pll) _MMIO(_PICK_EVEN_2RANGES(pll, 3,
> \
> + _DPLL0_ENABLE,
> _DPLL1_ENABLE,\
> +
> _ADLS_DPLL3_ENABLE, _ADLS_DPLL3_ENABLE))
>
> #define _DG2_PLL3_ENABLE 0x4601C
>
> -#define DG2_PLL_ENABLE(pll) _MMIO_PLL3(pll, _DPLL0_ENABLE,
> _DPLL1_ENABLE, \
> -_ADLS_DPLL2_ENABLE,
> _DG2_PLL3_ENABLE)
> +#define DG2_PLL_ENABLE(pll) _MMIO(_PICK_EVEN_2RANGES(pll, 3,
> \
> + _DPLL0_ENABLE,
> _DPLL1_ENABLE,\
> + _DG2_PLL3_ENABLE,
> _DG2_PLL3_ENABLE))
>
> #define TBT_PLL_ENABLE _MMIO(0x46020)
>
> @@ -7251,8 +7253,9 @@ enum skl_power_gate {
> _MG_PLL2_ENABLE)
>
> /* DG1 PLL */
> -#define DG1_DPLL_ENABLE(pll)_MMIO_PLL3(pll, _DPLL0_ENABLE,
> _DPLL1_ENABLE, \
> -_MG_PLL1_ENABLE,
> _MG_PLL2_ENABLE)
> +#define DG1_DPLL_ENABLE(pll)_MMIO(_PICK_EVEN_2RANGES(pll, 2,
> \
> + _DPLL0_ENABLE,
> _DPLL1_ENABLE,\
> + _MG_PLL1_ENABLE,
> _MG_PLL2_ENABLE))
>
> /* ADL-P Type C PLL */
> #define PORTTC1_PLL_ENABLE 0x46038
> @@ -7312,9 +7315,9 @@ enum skl_power_gate {
> #define _TGL_DPLL0_CFGCR00x164284
> #define _TGL_DPLL1_CFGCR00x16428C
> #define _TGL_TBTPLL_CFGCR0 0x16429C
> -#define TGL_DPLL_CFGCR0(pll) _MMIO_PLL3(pll,
> _TGL_DPLL0_CFGCR0, \
> - _TGL_DPLL1_CFGCR0, \
> - _TGL_TBTPLL_CFGCR0)
> +#define TGL_DPLL_CFGCR0(pll) _MMIO(_PICK_EVEN_2RANGES(pll, 2,
> \
> + _TGL_DPLL0_CFGCR0,
> _TGL_DPLL1_CFGCR0,\
> + _TGL_TBTPLL_CFGCR0,
> _TGL_TBTPLL_CFGCR0))
> #define RKL_DPLL_CFGCR0(pll) _MMIO_PLL(pll, _TGL_DPLL0_CFGCR0,
> \
> _TGL_DPLL1_CFGCR0)
>
> @@ -7327,40 +7330,36 @@ enum skl_power_gate {
> #define _TGL_DPLL0_CFGCR10x164288
> #define _TGL_DPLL1_CFGCR10x164290
> #define _TGL_TBTPLL_CFGCR1 0x1642A0
> -#define TGL_DPLL_CFGCR1(pll) _MMIO_PLL3(pll,
> _TGL_DPLL0_CFGCR1, \
> -_TGL_DPLL1_CFGCR1, \
> -
Re: [Intel-gfx] [PATCH v2.1] drm/i915: Add _PICK_EVEN_2RANGES()
> -Original Message- > From: De Marchi, Lucas > Sent: Monday, January 23, 2023 9:16 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Srivatsa, Anusha ; Jani Nikula > ; De Marchi, Lucas > Subject: [PATCH v2.1] drm/i915: Add _PICK_EVEN_2RANGES() > > It's a constant pattern in the driver to need to use 2 ranges of MMIOs based > on > port, phy, pll, etc. When that happens, instead of using _PICK_EVEN(), _PICK() > needs to be used. Using _PICK() is discouraged due to some reasons like: > > 1) It increases the code size since the array is declared >in each call site > 2) Developers need to be careful not to incur an >out-of-bounds array access > 3) Developers need to be careful that the indexes match the >table. For that it may be that the table needs to contain >holes, making (1) even worse. > > Add a variant of _PICK_EVEN() that works with 2 ranges and selects which one > to use depending on the index value. > > v2: Fix the address expansion in the example (Anusha) > > Signed-off-by: Lucas De Marchi Reviewed-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/i915_reg_defs.h | 28 > 1 file changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h > b/drivers/gpu/drm/i915/i915_reg_defs.h > index be43580a6979..bab6a9ec2ddd 100644 > --- a/drivers/gpu/drm/i915/i915_reg_defs.h > +++ b/drivers/gpu/drm/i915/i915_reg_defs.h > @@ -119,6 +119,34 @@ > */ > #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a))) > > +/* > + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets. > + * The first range is used for indexes below @__c_index, and the second > + * range is used for anything above it. Example:: > + * > + * #define _FOO_A0xf000 > + * #define _FOO_B0xf004 > + * #define _FOO_C0xf008 > + * #define _SUPER_FOO_A 0xa000 > + * #define _SUPER_FOO_B 0xa100 > + * #define FOO(x)_MMIO(_PICK_EVEN_RANGES(x, 3, > \ > + * _FOO_A, _FOO_B, > \ > + * _SUPER_FOO_A, _SUPER_FOO_B)) > + * > + * This expands to: > + * 0: 0xf000, > + * 1: 0xf004, > + * 2: 0xf008, > + * 3: 0xa000, > + * 4: 0xa100, > + * 5: 0xa200, > + * ... > + */ > +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) > \ > + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + > \ > + ((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : > \ > +_PICK_EVEN((__index) - (__c_index), __c, > __d))) > + > /* > * Given the arbitrary numbers in varargs, pick the 0-based __index'th > number. > * > -- > 2.39.0
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
> -Original Message- > From: Jani Nikula > Sent: Monday, January 23, 2023 3:01 AM > To: De Marchi, Lucas ; Srivatsa, Anusha > > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES() > > On Sat, 21 Jan 2023, Lucas De Marchi wrote: > > On Fri, Jan 20, 2023 at 10:14:19PM -0800, Anusha Srivatsa wrote: > >> > >> > >>> -Original Message- > >>> From: Intel-gfx On Behalf > >>> Of Lucas De Marchi > >>> Sent: Friday, January 20, 2023 11:35 AM > >>> To: intel-gfx@lists.freedesktop.org > >>> Cc: De Marchi, Lucas ; dri- > >>> de...@lists.freedesktop.org > >>> Subject: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add > >>> _PICK_EVEN_2RANGES() > >>> > >>> It's a constant pattern in the driver to need to use 2 ranges of > >>> MMIOs based on port, phy, pll, etc. When that happens, instead of > >>> using _PICK_EVEN(), _PICK() needs to be used. Using _PICK() is > >>> discouraged > due to some reasons like: > >>> > >>> 1) It increases the code size since the array is declared > >>>in each call site > >>> 2) Developers need to be careful not to incur an > >>>out-of-bounds array access > >>> 3) Developers need to be careful that the indexes match the > >>>table. For that it may be that the table needs to contain > >>>holes, making (1) even worse. > >>> > >>> Add a variant of _PICK_EVEN() that works with 2 ranges and selects > >>> which one to use depending on the index value. > >>> > >>> Signed-off-by: Lucas De Marchi > >>> --- > >>> drivers/gpu/drm/i915/i915_reg_defs.h | 28 > >>> > >>> 1 file changed, 28 insertions(+) > >>> > >>> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h > >>> b/drivers/gpu/drm/i915/i915_reg_defs.h > >>> index be43580a6979..b7ec87464d69 100644 > >>> --- a/drivers/gpu/drm/i915/i915_reg_defs.h > >>> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h > >>> @@ -119,6 +119,34 @@ > >>> */ > >>> #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - > >>> (__a))) > >>> > >>> +/* > >>> + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address > offsets. > >>> + * The first range is used for indexes below @__c_index, and the > >>> +second > >>> + * range is used for anything above it. Example:: > >>> + * > >>> + * #define _FOO_A0xf000 > >>> + * #define _FOO_B0xf004 > >>> + * #define _FOO_C0xf008 > >>> + * #define _SUPER_FOO_A 0xa000 > >>> + * #define _SUPER_FOO_B 0xa100 > >>> + * #define FOO(x)_MMIO(_PICK_EVEN_RANGES(x, 3, > >>> \ > >>> + * _FOO_A, _FOO_B, > >>> \ > >>> + * _SUPER_FOO_A, > >>> _SUPER_FOO_B)) > >>> + * > >>> + * This expands to: > >>> + * 0: 0xf000, > >>> + * 1: 0xf004, > >>> + * 2: 0xf008, > >>> + * 3: 0xa100, > >>You mean 3:0xa000 > > > > doesn't really matter. This is an example of register addresses. They > > don't need to start from 0, it's whatever the hw gives us. > > I think the point is that the example is inconsistent between _SUPER_FOO_A and > "3: 0xa100". Yes. It's the inconsistency with _SUPER_FOO_A that I was pointing out. Anusha > BR, > Jani. > > > > > Lucas De Marchi > > > >> > >>> + * 4: 0xa200, > >>4:0xa100 > >> > >>> + * 5: 0xa300, > >>5:0xa200 > >> > >>Anusha > >>> + * ... > >>> + */ > >>> +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) > >>> \ > >>> + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + > >>> \ > >>> + ((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : > >>> \ > >>> +_PICK_EVEN((__index) - (__c_index), __c, > >>> __d))) > >>> + > >>> /* > >>> * Given the arbitrary numbers in varargs, pick the 0-based __index'th > number. > >>> * > >>> -- > >>> 2.39.0 > >> > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
> -Original Message- > From: Intel-gfx On Behalf Of Lucas > De Marchi > Sent: Friday, January 20, 2023 11:35 AM > To: intel-gfx@lists.freedesktop.org > Cc: De Marchi, Lucas ; dri- > de...@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES() > > It's a constant pattern in the driver to need to use 2 ranges of MMIOs based > on > port, phy, pll, etc. When that happens, instead of using _PICK_EVEN(), _PICK() > needs to be used. Using _PICK() is discouraged due to some reasons like: > > 1) It increases the code size since the array is declared >in each call site > 2) Developers need to be careful not to incur an >out-of-bounds array access > 3) Developers need to be careful that the indexes match the >table. For that it may be that the table needs to contain >holes, making (1) even worse. > > Add a variant of _PICK_EVEN() that works with 2 ranges and selects which one > to use depending on the index value. > > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_reg_defs.h | 28 > 1 file changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h > b/drivers/gpu/drm/i915/i915_reg_defs.h > index be43580a6979..b7ec87464d69 100644 > --- a/drivers/gpu/drm/i915/i915_reg_defs.h > +++ b/drivers/gpu/drm/i915/i915_reg_defs.h > @@ -119,6 +119,34 @@ > */ > #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a))) > > +/* > + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets. > + * The first range is used for indexes below @__c_index, and the second > + * range is used for anything above it. Example:: > + * > + * #define _FOO_A0xf000 > + * #define _FOO_B0xf004 > + * #define _FOO_C0xf008 > + * #define _SUPER_FOO_A 0xa000 > + * #define _SUPER_FOO_B 0xa100 > + * #define FOO(x)_MMIO(_PICK_EVEN_RANGES(x, 3, > \ > + * _FOO_A, _FOO_B, > \ > + * _SUPER_FOO_A, _SUPER_FOO_B)) > + * > + * This expands to: > + * 0: 0xf000, > + * 1: 0xf004, > + * 2: 0xf008, > + * 3: 0xa100, You mean 3:0xa000 > + * 4: 0xa200, 4:0xa100 > + * 5: 0xa300, 5:0xa200 Anusha > + * ... > + */ > +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d) > \ > + (BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) + > \ > + ((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) : > \ > +_PICK_EVEN((__index) - (__c_index), __c, > __d))) > + > /* > * Given the arbitrary numbers in varargs, pick the 0-based __index'th > number. > * > -- > 2.39.0
Re: [Intel-gfx] [PATCH v2 8/8] drm/i915: Convert PALETTE() to _PICK_EVEN_2RANGES()
> -Original Message- > From: Intel-gfx On Behalf Of Lucas > De Marchi > Sent: Friday, January 20, 2023 11:35 AM > To: intel-gfx@lists.freedesktop.org > Cc: De Marchi, Lucas ; dri- > de...@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 8/8] drm/i915: Convert PALETTE() to > _PICK_EVEN_2RANGES() > > PALETTE() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the > size and is safer. > > Signed-off-by: Lucas De Marchi Reviewed-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/i915_reg.h | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 3d6ad4424265..b134a1f357c8 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1734,10 +1734,11 @@ > #define PALETTE_10BIT_BLUE_EXP_MASKREG_GENMASK(7, 6) > #define PALETTE_10BIT_BLUE_MANT_MASK REG_GENMASK(5, 2) > #define PALETTE_10BIT_BLUE_UDW_MASKREG_GENMASK(1, 0) > -#define PALETTE(pipe, i) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ > - _PICK((pipe), _PALETTE_A, \ > - _PALETTE_B, _CHV_PALETTE_C) + \ > - (i) * 4) > +#define PALETTE(pipe, i) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + > \ > +_PICK_EVEN_2RANGES(pipe, 2, > \ > + _PALETTE_A, _PALETTE_B, > \ > + _CHV_PALETTE_C, > _CHV_PALETTE_C) + \ > + (i) * 4) > > #define PEG_BAND_GAP_DATA_MMIO(0x14d68) > > -- > 2.39.0
Re: [Intel-gfx] [PATCH v2 7/8] drm/i915: Convert MBUS_ABOX_CTL() to _PICK_EVEN_2RANGES()
> -Original Message- > From: Intel-gfx On Behalf Of Lucas > De Marchi > Sent: Friday, January 20, 2023 11:35 AM > To: intel-gfx@lists.freedesktop.org > Cc: De Marchi, Lucas ; dri- > de...@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 7/8] drm/i915: Convert MBUS_ABOX_CTL() to > _PICK_EVEN_2RANGES() > > MBUS_ABOX_CTL() can use _PICK_EVEN_2RANGES instead of _PICK, which > reduces the size and is safer. > > Signed-off-by: Lucas De Marchi Looks good! Reviewed-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/i915_reg.h | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index fe6385443c4a..3d6ad4424265 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1040,9 +1040,11 @@ > #define _MBUS_ABOX0_CTL 0x45038 > #define _MBUS_ABOX1_CTL 0x45048 > #define _MBUS_ABOX2_CTL 0x4504C > -#define MBUS_ABOX_CTL(x) _MMIO(_PICK(x, _MBUS_ABOX0_CTL, > \ > - _MBUS_ABOX1_CTL, \ > - _MBUS_ABOX2_CTL)) > +#define MBUS_ABOX_CTL(x) > \ > + _MMIO(_PICK_EVEN_2RANGES(x, 2, > \ > + _MBUS_ABOX0_CTL, _MBUS_ABOX1_CTL, > \ > + _MBUS_ABOX2_CTL, _MBUS_ABOX2_CTL)) > + > #define MBUS_ABOX_BW_CREDIT_MASK (3 << 20) > #define MBUS_ABOX_BW_CREDIT(x) ((x) << 20) > #define MBUS_ABOX_B_CREDIT_MASK (0xF << 16) > -- > 2.39.0
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Convert _FIA() to _PICK_EVEN_2RANGES()
> -Original Message- > From: Intel-gfx On Behalf Of Lucas > De Marchi > Sent: Friday, January 20, 2023 11:35 AM > To: intel-gfx@lists.freedesktop.org > Cc: De Marchi, Lucas ; dri- > de...@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 6/8] drm/i915: Convert _FIA() to > _PICK_EVEN_2RANGES() > > _FIA() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the size > and is safer. > > Signed-off-by: Lucas De Marchi Reviewed-by: Anusha Srivatsa > --- > drivers/gpu/drm/i915/display/intel_mg_phy_regs.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_mg_phy_regs.h > b/drivers/gpu/drm/i915/display/intel_mg_phy_regs.h > index 0e8248bce52d..0306ade2bc30 100644 > --- a/drivers/gpu/drm/i915/display/intel_mg_phy_regs.h > +++ b/drivers/gpu/drm/i915/display/intel_mg_phy_regs.h > @@ -142,7 +142,9 @@ > #define FIA1_BASE0x163000 > #define FIA2_BASE0x16E000 > #define FIA3_BASE0x16F000 > -#define _FIA(fia)_PICK((fia), FIA1_BASE, FIA2_BASE, > FIA3_BASE) > +#define _FIA(fia)_PICK_EVEN_2RANGES((fia), 1, > \ > +FIA1_BASE, > FIA1_BASE,\ > +FIA2_BASE, > FIA3_BASE) > #define _MMIO_FIA(fia, off) _MMIO(_FIA(fia) + (off)) > > /* ICL PHY DFLEX registers */ > -- > 2.39.0
Re: [Intel-gfx] [PATCH v2 5/8] drm/i915: Convert PIPE3/PORT3 to _PICK_EVEN_2RANGES()
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 5/8] drm/i915: Convert PIPE3/PORT3 to
> _PICK_EVEN_2RANGES()
>
> Like done for when __var_args__ were used, but size-wise it's also benefitial
> to
> avoid _PICK() used for 3 ports/pipes:
>
> $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new}
> textdata bss dec hex filename
> 4026288 1857036984 4218975 40605f
> build64/drivers/gpu/drm/i915/i915.o.old
> 4025496 1857036984 4218183 405d47
> build64/drivers/gpu/drm/i915/i915.o.new
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_display_reg_defs.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> index f1681e1396b5..755c1ea8225c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> @@ -13,7 +13,7 @@
> #define VLV_DISPLAY_BASE 0x18
>
> /*
> - * Named helper wrappers around _PICK_EVEN() and _PICK().
> + * Named helper wrappers around _PICK_EVEN() and _PICK_EVEN_2RANGES().
> */
> #define _PIPE(pipe, a, b)_PICK_EVEN(pipe, a, b)
> #define _PLANE(plane, a, b) _PICK_EVEN(plane, a, b)
> @@ -29,8 +29,8 @@
> #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
> #define _MMIO_PHY(phy, a, b) _MMIO(_PHY(phy, a, b))
>
> -#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> -#define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> +#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK_EVEN_2RANGES(pipe,
> 1, a, a, b, c))
> +#define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK_EVEN_2RANGES(pipe,
> 1, a, a, b, c))
>
> /*
> * Device info offset array based helpers for groups of registers with
> unevenly
> --
> 2.39.0
Re: [Intel-gfx] [PATCH v2 4/8] drm/i915: Replace _MMIO_PHY3() with _PICK_EVEN_2RANGES()
Verified that the new macro evaluates to the right register offsets.
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 4/8] drm/i915: Replace _MMIO_PHY3() with
> _PICK_EVEN_2RANGES()
>
> As done previously for pll, also convert users of _PHY3() to
> _PICK_EVEN_2RANGES(). Size comparison of i915.o:
>
> $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new}
> textdata bss dec hex filename
> 4026997 1857036984 4219684 406324
> build64/drivers/gpu/drm/i915/i915.o.old
> 4026288 1857036984 4218975 40605f
> build64/drivers/gpu/drm/i915/i915.o.new
>
> Signed-off-by: Lucas De Marchi
> ---
> .../drm/i915/display/intel_display_reg_defs.h| 3 ---
> drivers/gpu/drm/i915/i915_reg.h | 16 +---
> 2 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> index a4ed1c530799..f1681e1396b5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_reg_defs.h
> @@ -29,11 +29,8 @@
> #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
> #define _MMIO_PHY(phy, a, b) _MMIO(_PHY(phy, a, b))
>
> -#define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
> -
> #define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> -#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>
> /*
> * Device info offset array based helpers for groups of registers with
> unevenly
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index dd1eb8b10e0e..fe6385443c4a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -541,9 +541,10 @@
> #define _BXT_PHY0_BASE 0x6C000
> #define _BXT_PHY1_BASE 0x162000
> #define _BXT_PHY2_BASE 0x163000
> -#define BXT_PHY_BASE(phy)_PHY3((phy), _BXT_PHY0_BASE, \
> - _BXT_PHY1_BASE, \
> - _BXT_PHY2_BASE)
> +#define BXT_PHY_BASE(phy)
> \
> + _PICK_EVEN_2RANGES(phy, 1,
> \
> + _BXT_PHY0_BASE, _BXT_PHY0_BASE,
> \
> + _BXT_PHY1_BASE, _BXT_PHY2_BASE)
>
> #define _BXT_PHY(phy, reg) \
> _MMIO(BXT_PHY_BASE(phy) - _BXT_PHY0_BASE + (reg)) @@ -566,13
> +567,14 @@
> #define BXT_PHY_CTL(port)_MMIO_PORT(port,
> _BXT_PHY_CTL_DDI_A, \
>
> _BXT_PHY_CTL_DDI_B)
>
> -#define _PHY_CTL_FAMILY_EDP 0x64C80
> #define _PHY_CTL_FAMILY_DDI 0x64C90
> +#define _PHY_CTL_FAMILY_EDP 0x64C80
> #define _PHY_CTL_FAMILY_DDI_C0x64CA0
> #define COMMON_RESET_DIS (1 << 31)
> -#define BXT_PHY_CTL_FAMILY(phy) _MMIO_PHY3((phy),
> _PHY_CTL_FAMILY_DDI, \
> -
> _PHY_CTL_FAMILY_EDP, \
> -
> _PHY_CTL_FAMILY_DDI_C)
> +#define BXT_PHY_CTL_FAMILY(phy)
> \
> + _MMIO(_PICK_EVEN_2RANGES(phy, 1,
> \
> + _PHY_CTL_FAMILY_DDI,
> _PHY_CTL_FAMILY_DDI, \
> + _PHY_CTL_FAMILY_EDP,
> _PHY_CTL_FAMILY_DDI_C))
>
> /* BXT PHY PLL registers */
> #define _PORT_PLL_A 0x46074
> --
> 2.39.0
Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Fix coding style on DPLL*_ENABLE defines
Changes look good.
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 2/8] drm/i915: Fix coding style on DPLL*_ENABLE
> defines
>
> Abide by the rules in the top of the header: 2 spaces for bitfield, prefix
> offsets
> with underscore and prefer the use of REG_BIT().
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3b2642397b82..8da3546d82fb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7224,20 +7224,20 @@ enum skl_power_gate {
>
> ADLS_DPCLKA_DDIK_SEL_MASK)
>
> /* ICL PLL */
> -#define DPLL0_ENABLE 0x46010
> -#define DPLL1_ENABLE 0x46014
> +#define _DPLL0_ENABLE0x46010
> +#define _DPLL1_ENABLE0x46014
> #define _ADLS_DPLL2_ENABLE 0x46018
> #define _ADLS_DPLL3_ENABLE 0x46030
> -#define PLL_ENABLE (1 << 31)
> -#define PLL_LOCK(1 << 30)
> -#define PLL_POWER_ENABLE(1 << 27)
> -#define PLL_POWER_STATE (1 << 26)
> -#define ICL_DPLL_ENABLE(pll) _MMIO_PLL3(pll, DPLL0_ENABLE,
> DPLL1_ENABLE, \
> +#define PLL_ENABLE REG_BIT(31)
> +#define PLL_LOCK REG_BIT(30)
> +#define PLL_POWER_ENABLE REG_BIT(27)
> +#define PLL_POWER_STATEREG_BIT(26)
> +#define ICL_DPLL_ENABLE(pll) _MMIO_PLL3(pll, _DPLL0_ENABLE,
> _DPLL1_ENABLE, \
> _ADLS_DPLL2_ENABLE,
> _ADLS_DPLL3_ENABLE)
>
> #define _DG2_PLL3_ENABLE 0x4601C
>
> -#define DG2_PLL_ENABLE(pll) _MMIO_PLL3(pll, DPLL0_ENABLE,
> DPLL1_ENABLE, \
> +#define DG2_PLL_ENABLE(pll) _MMIO_PLL3(pll, _DPLL0_ENABLE,
> +_DPLL1_ENABLE, \
> _ADLS_DPLL2_ENABLE,
> _DG2_PLL3_ENABLE)
>
> #define TBT_PLL_ENABLE _MMIO(0x46020)
> @@ -7246,12 +7246,12 @@ enum skl_power_gate {
> #define _MG_PLL2_ENABLE 0x46034
> #define _MG_PLL3_ENABLE 0x46038
> #define _MG_PLL4_ENABLE 0x4603C
> -/* Bits are the same as DPLL0_ENABLE */
> +/* Bits are the same as _DPLL0_ENABLE */
> #define MG_PLL_ENABLE(tc_port) _MMIO_PORT((tc_port),
> _MG_PLL1_ENABLE, \
> _MG_PLL2_ENABLE)
>
> /* DG1 PLL */
> -#define DG1_DPLL_ENABLE(pll)_MMIO_PLL3(pll, DPLL0_ENABLE,
> DPLL1_ENABLE, \
> +#define DG1_DPLL_ENABLE(pll)_MMIO_PLL3(pll, _DPLL0_ENABLE,
> _DPLL1_ENABLE, \
> _MG_PLL1_ENABLE,
> _MG_PLL2_ENABLE)
>
> /* ADL-P Type C PLL */
> --
> 2.39.0
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for CDCLK PLL disable/enable
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Thursday, December 15, 2022 2:14 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for
> CDCLK PLL disable/enable
>
> On Wed, Dec 14, 2022 at 09:15:07PM +0200, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Lisovskiy, Stanislav
> > > Sent: Wednesday, December 14, 2022 2:31 AM
> > > To: Srivatsa, Anusha
> > > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> > >
> > > Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround
> > > for CDCLK PLL disable/enable
> > >
> > > On Tue, Nov 29, 2022 at 09:19:40PM +0200, Srivatsa, Anusha wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Intel-gfx On
> > > > > Behalf Of Stanislav Lisovskiy
> > > > > Sent: Thursday, November 24, 2022 2:36 AM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: Nikula, Jani
> > > > > Subject: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround
> > > > > for CDCLK PLL disable/enable
> > > > >
> > > > > It was reported that we might get a hung and loss of register
> > > > > access in some cases when CDCLK PLL is disabled and then
> > > > > enabled, while squashing is enabled.
> > > > > As a workaround it was proposed by HW team that SW should
> > > > > disable squashing when CDCLK PLL is being reenabled.
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 14 --
> > > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > index 0c107a38f9d0..e338f288c9ac 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > @@ -1801,6 +1801,13 @@ static bool
> > > > > cdclk_compute_crawl_and_squash_midpoint(struct
> drm_i915_private
> > > *i91
> > > > > return true;
> > > > > }
> > > > >
> > > > > +static bool pll_enable_wa_needed(struct drm_i915_private
> > > > > +*dev_priv)
> > > {
> > > > > + return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
> > > > > + && dev_priv->display.cdclk.hw.vco > 0
> > > > > + && HAS_CDCLK_SQUASH(dev_priv));
> > > > Redundant check. If it is MTL or DG2, then it will have
> > > HAS_CDCLK_SQUASH set to true always. Shouldn't vco be 0 instead of >
> 0.
> > > The commit message says the hang can be observed when moving from
> 0
> > > to
> > > > 0 vco.
> > > >
> > > > Anusha
> > >
> > > Idea was that we probably should bind more to the feature rather
> > > than platform, I agree checking both "IS_DG2" and if platform has
> > > squashing is redundant, because then we would have to add each new
> > > platform manually, so I would leave HAS_CDCLK_SQUASH and then at
> > > some point just cut off using some INTEL_GEN or other check all the
> > > new platforms where this is fixed in HW.
> > >
> > > Regarding vco, the icl_cdclk_pll_update func works as follows:
> > >
> > > if (i915->display.cdclk.hw.vco != 0 &&
> > > i915->display.cdclk.hw.vco != vco)
> > > icl_cdclk_pll_disable(i915);
> > >
> > > if (i915->display.cdclk.hw.vco != vco)
> > > icl_cdclk_pll_enable(i915, vco);
> > >
> > > 1) if vco changes from zero value(i915->display.cdclk.hw.vco) to
> > > non-zero value(vco), that means
> > >currently squashing is anyway disabled(if vco == 0, cdclk is set to
> "bypass"
> > > and squash waveform
> > >is 0), so the W/A is not needed.
> > >
> > > 2) if vco changes from non-zero value in i915->display.cdclk.hw.vco
> > > to zero value(vco), we are not
> > >going to call icl_cdclk_pll_enable anyway so W/A is also not needed.
> >
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for CDCLK PLL disable/enable
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Wednesday, December 14, 2022 2:31 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for
> CDCLK PLL disable/enable
>
> On Tue, Nov 29, 2022 at 09:19:40PM +0200, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf
> > > Of Stanislav Lisovskiy
> > > Sent: Thursday, November 24, 2022 2:36 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Nikula, Jani
> > > Subject: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for
> > > CDCLK PLL disable/enable
> > >
> > > It was reported that we might get a hung and loss of register access
> > > in some cases when CDCLK PLL is disabled and then enabled, while
> > > squashing is enabled.
> > > As a workaround it was proposed by HW team that SW should disable
> > > squashing when CDCLK PLL is being reenabled.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 14 --
> > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 0c107a38f9d0..e338f288c9ac 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1801,6 +1801,13 @@ static bool
> > > cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> *i91
> > > return true;
> > > }
> > >
> > > +static bool pll_enable_wa_needed(struct drm_i915_private *dev_priv)
> {
> > > + return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
> > > + && dev_priv->display.cdclk.hw.vco > 0
> > > + && HAS_CDCLK_SQUASH(dev_priv));
> > Redundant check. If it is MTL or DG2, then it will have
> HAS_CDCLK_SQUASH set to true always. Shouldn't vco be 0 instead of > 0.
> The commit message says the hang can be observed when moving from 0 to
> > 0 vco.
> >
> > Anusha
>
> Idea was that we probably should bind more to the feature rather than
> platform, I agree checking both "IS_DG2" and if platform has squashing is
> redundant, because then we would have to add each new platform
> manually, so I would leave HAS_CDCLK_SQUASH and then at some point
> just cut off using some INTEL_GEN or other check all the new platforms
> where this is fixed in HW.
>
> Regarding vco, the icl_cdclk_pll_update func works as follows:
>
> if (i915->display.cdclk.hw.vco != 0 &&
> i915->display.cdclk.hw.vco != vco)
> icl_cdclk_pll_disable(i915);
>
> if (i915->display.cdclk.hw.vco != vco)
> icl_cdclk_pll_enable(i915, vco);
>
> 1) if vco changes from zero value(i915->display.cdclk.hw.vco) to non-zero
> value(vco), that means
>currently squashing is anyway disabled(if vco == 0, cdclk is set to
> "bypass"
> and squash waveform
>is 0), so the W/A is not needed.
>
> 2) if vco changes from non-zero value in i915->display.cdclk.hw.vco to zero
> value(vco), we are not
>going to call icl_cdclk_pll_enable anyway so W/A is also not needed.
>
> 3) if vco changes from some non-zero value in i915->display.cdclk.hw.vco to
> other non-zero value(vco),
>which can happen if CDCLK changes, then icl_cdclk_pll_disable(hw vco!=0
> and vco!=0) and then
>icl_cdclk_pll_enable would be called(hw vco is still not equal to vco)
>So that disabling enabling in between is what we are interested and
> where we should make sure
>squashing is disabled.
>BTW I have another question - is this code even correct? Shouldn't we
> avoid disabling/enabling PLL if we have
>squashing/crawling? As I understood the whole point of having
> swuashing/crawling is avoiding swithing the PLL
>on and off.
>
Squashing works when we don't need to change the PLL ratio. We fix the PLL
ratio to say 307 (this can change from platform to platform). Then squashing
can be used to vary frequencies below this. So we set squasher to it will
mean highest. We can use squasher to change frequency with squash waveform, max
being and any value lower will take lower frequencies.
Cdclk Crawling is used when the PLL has to be changed. Eg higher than 307 then
we need to update PLL. In that case we first program squashing to (this
will take to 307) n then use crawling to go up to t
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for CDCLK PLL disable/enable
> -Original Message-
> From: Intel-gfx On Behalf Of
> Stanislav Lisovskiy
> Sent: Thursday, November 24, 2022 2:36 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH 1/1] drm/i915: Implement workaround for CDCLK
> PLL disable/enable
>
> It was reported that we might get a hung and loss of register access in some
> cases when CDCLK PLL is disabled and then enabled, while squashing is
> enabled.
> As a workaround it was proposed by HW team that SW should disable
> squashing when CDCLK PLL is being reenabled.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 0c107a38f9d0..e338f288c9ac 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1801,6 +1801,13 @@ static bool
> cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private *i91
> return true;
> }
>
> +static bool pll_enable_wa_needed(struct drm_i915_private *dev_priv) {
> + return ((IS_DG2(dev_priv) || IS_METEORLAKE(dev_priv))
> + && dev_priv->display.cdclk.hw.vco > 0
> + && HAS_CDCLK_SQUASH(dev_priv));
Redundant check. If it is MTL or DG2, then it will have HAS_CDCLK_SQUASH set to
true always. Shouldn't vco be 0 instead of > 0. The commit message says the
hang can be observed when moving from 0 to > 0 vco.
Anusha
> +}
> +
> static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
> const struct intel_cdclk_config *cdclk_config,
> enum pipe pipe)
> @@ -1815,9 +1822,12 @@ static void _bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> !cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
> if (dev_priv->display.cdclk.hw.vco != vco)
> adlp_cdclk_pll_crawl(dev_priv, vco);
> - } else if (DISPLAY_VER(dev_priv) >= 11)
> + } else if (DISPLAY_VER(dev_priv) >= 11) {
> + if (pll_enable_wa_needed(dev_priv))
> + dg2_cdclk_squash_program(dev_priv, 0);
> +
> icl_cdclk_pll_update(dev_priv, vco);
> - else
> + } else
> bxt_cdclk_pll_update(dev_priv, vco);
>
> waveform = cdclk_squash_waveform(dev_priv, cdclk);
> --
> 2.37.3
Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Update DG2 DMC version to v2.08
Thanks, looked at the rest of the platforms in the file and the changes look good. Reviewed-by: Anusha Srivatsa > -Original Message- > From: Sousa, Gustavo > Sent: Tuesday, November 22, 2022 10:06 AM > To: Srivatsa, Anusha ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Update DG2 DMC version > to v2.08 > > Hi, Anusha. > > On Tue, Nov 22, 2022 at 02:27:05PM -0300, Srivatsa, Anusha wrote: > > > > > > > -Original Message- > > > From: Intel-gfx On Behalf > > > Of Gustavo Sousa > > > Sent: Tuesday, November 22, 2022 4:14 AM > > > To: intel-gfx@lists.freedesktop.org > > > Subject: [Intel-gfx] [PATCH v2] drm/i915/dmc: Update DG2 DMC version > > > to > > > v2.08 > > > > > > Release notes: > > > > > > 1. Fixes for Register noclaims and few restore. > > > > > > Signed-off-by: Gustavo Sousa > > > --- > > > > > > v2: > > > - Use correct numbering for the minor version (8 instead of the > > > invalid octal 08). > > > > > > drivers/gpu/drm/i915/display/intel_dmc.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c > > > b/drivers/gpu/drm/i915/display/intel_dmc.c > > > index 081a4d0083b1..eff3add70611 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_dmc.c > > > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c > > > @@ -52,8 +52,8 @@ > > > > > > #define DISPLAY_VER12_DMC_MAX_FW_SIZE > ICL_DMC_MAX_FW_SIZE > > > > > > -#define DG2_DMC_PATH DMC_PATH(dg2, 2, 07) > > > -#define DG2_DMC_VERSION_REQUIRED DMC_VERSION(2, 07) > > > +#define DG2_DMC_PATH DMC_PATH(dg2, 2, 08) > > > +#define DG2_DMC_VERSION_REQUIRED DMC_VERSION(2, 8) > > ^this should be > (2,08) > > The v1 was using 08, but the problem is that this value is interpreted as a > bad > octal, and that caused the compiler to rightfully complain about it :-). > > While the path should contain the "08", I believe the version required must > contain valid numbers and we should represent them in the decimal base. > There are other similar examples in this file. > > -- > Gustavo Sousa
Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Update DG2 DMC version to v2.08
> -Original Message- > From: Intel-gfx On Behalf Of > Gustavo Sousa > Sent: Tuesday, November 22, 2022 4:14 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2] drm/i915/dmc: Update DG2 DMC version to > v2.08 > > Release notes: > > 1. Fixes for Register noclaims and few restore. > > Signed-off-by: Gustavo Sousa > --- > > v2: > - Use correct numbering for the minor version (8 instead of the > invalid octal 08). > > drivers/gpu/drm/i915/display/intel_dmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c > b/drivers/gpu/drm/i915/display/intel_dmc.c > index 081a4d0083b1..eff3add70611 100644 > --- a/drivers/gpu/drm/i915/display/intel_dmc.c > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c > @@ -52,8 +52,8 @@ > > #define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE > > -#define DG2_DMC_PATH DMC_PATH(dg2, 2, 07) > -#define DG2_DMC_VERSION_REQUIRED DMC_VERSION(2, 07) > +#define DG2_DMC_PATH DMC_PATH(dg2, 2, 08) > +#define DG2_DMC_VERSION_REQUIRED DMC_VERSION(2, 8) ^this should be (2,08) Anusha > MODULE_FIRMWARE(DG2_DMC_PATH); > > #define ADLP_DMC_PATHDMC_PATH(adlp, 2, 16) > -- > 2.38.1
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Wednesday, November 16, 2022 10:44 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Vivekanandan, Balasubramani
>
> Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and
> squash when changing cdclk
>
> On Wed, Nov 16, 2022 at 06:50:07AM -0800, Anusha Srivatsa wrote:
> > From: Ville Syrjälä
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > Driver should not take some Pcode mailbox communication in the cdclk
> > path for platforms that are Display 14 and later.
>
> Nit: display _version_ 14 and later.
>
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > v4: Rebase
> > - Move checks to be more consistent (Ville)
> > - Add comments (Bala)
> > v5:
> > - Further small changes. Move checks around.
> > - Make if-else better looking (Ville)
> >
> > v6: MTl should not follow PUnit mailbox communication as the rest of
> > gen11+ platforms.(Anusha)
> >
> > Cc: Clint Taylor
> > Cc: Balasubramani Vivekanandan
>
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 175
> > +
> > 1 file changed, 144 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 25d01271dc09..6e122d56428c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1727,37 +1727,75 @@ static bool cdclk_pll_is_unknown(unsigned int
> vco)
> > return vco == ~0;
> > }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > + return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_compute_crawl_and_squash_midpoint(struct
> drm_i915_private *i915,
> > + const struct
> intel_cdclk_config *old_cdclk_config,
> > + const struct
> intel_cdclk_config *new_cdclk_config,
> > + struct intel_cdclk_config
> *mid_cdclk_config) {
> > + u16 old_waveform, new_waveform, mid_waveform;
> > + int size = 16;
> > + int div = 2;
> > +
> > + /* Return if both Squash and Crawl are not present */
> > + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > + return false;
> > +
> > + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config-
> >cdclk);
> > +
> > + /* Return if Squash only or Crawl only is the desired action */
> > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
>
> We still have "<= 0" checks here. As noted before, the < part can never
> evaluate to true since vco is an unsigned value. I think you meant to update
> this to include a check with your new cdclk_pll_is_unknown() helper?
Argh. No the check here should just be vco==0. For the case ~0 or the signed
value, we have it covered in bxt_set_cdclk() where we end up not taking the
crawl path.
> Also, the comment above this check says "if squash only or crawl only is the
> desired action" which is what the "==" conditions below cover. But the vco
> 0/unknown checks are technically to ensure we bail out if the desired action
> is to do neither of the two (traditional modeset).
>
> > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > + old_waveform == new_waveform)
> > + return false;
> > +
> > + *mid_cdclk_config = *new_cdclk_config;
> > +
> >
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, November 14, 2022 4:43 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
>
> Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash when
> changing cdclk
>
> On Mon, Nov 14, 2022 at 04:07:13PM -0800, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Roper, Matthew D
> > > Sent: Monday, November 14, 2022 4:01 PM
> > > To: Srivatsa, Anusha
> > > Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
> > >
> > > Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash
> > > when changing cdclk
> > >
> > > On Mon, Nov 14, 2022 at 03:14:33PM -0800, Srivatsa, Anusha wrote:
> > > ...
> > > > > > +static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > > > > + const struct intel_cdclk_config *cdclk_config,
> > > > > > + enum pipe pipe)
> > > > > > +{
> > > > > > + struct intel_cdclk_config mid_cdclk_config;
> > > > > > + int cdclk = cdclk_config->cdclk;
> > > > > > + int ret;
> > > > >
> > > > > You should initialize ret to 0 here since you don't set it in
> > > > > the new branch of the if/else ladder below.
> > > > >
> > > > > > +
> > > > > > + /* Inform power controller of upcoming frequency change.
> */
> > > > > > + if (DISPLAY_VER(dev_priv) >= 14) {
> > > > > > + /* DISPLAY14+ do not follow the PUnit mailbox
> > > > > communication,
> > > > >
> > > > > "Display versions 14 and above" or "Xe_LPD+ and beyond"
> > > > >
> > > > > Also, this is another case where "/*" should be on its own line.
> > > > >
> > > > > > +* skip this step.
> > > > > > +*/
> > > > > > + } else if (DISPLAY_VER(dev_priv) >= 11) {
> > > > > > + ret = skl_pcode_request(_priv->uncore,
> > > > > SKL_PCODE_CDCLK_CONTROL,
> > > > > > +
> SKL_CDCLK_PREPARE_FOR_CHANGE,
> > > > > > +
> SKL_CDCLK_READY_FOR_CHANGE,
> > > > > > +
> SKL_CDCLK_READY_FOR_CHANGE, 3);
> > > > > > } else {
> > > > > > /*
> > > > > > -* The timeout isn't specified, the 2ms used here is
> based on
> > > > > > -* experiment.
> > > > > > -* FIXME: Waiting for the request completion could
> be
> > > > > delayed
> > > > > > -* until the next PCODE request based on BSpec.
> > > > > > +* BSpec requires us to wait up to 150usec, but that
> leads to
> > > > > > +* timeouts; the 2ms used here is based on
> experiment.
> > > > > > */
> > > > > > ret = snb_pcode_write_timeout(_priv->uncore,
> > > > > >
> > > > > HSW_PCODE_DE_WRITE_FREQ_REQ,
> > > > > > - cdclk_config-
> >voltage_level,
> > > > > > - 150, 2);
> > > > > > + 0x8000, 150, 2);
> > > > >
> > > > > The switch from cdclk_config->voltage_level to a magic number
> > > > > (0x8000) on old platforms doesn't seem to be related to the
> > > > > rest of this patch. Ditto for the comment update about 150usec
> > > > > not being
> > > enough.
> > > > > Were those intended for a different patch?
> > > > Well, initially both squash and crawl support for MTl was the
> > > > intention. The change came to be a part of this patch because MTL
> > > > doesn't go through the Punit mailbox communication like previous
> > > > platforms and hence the churn. Thinking out loud if changing the
> > > > commit message makes more sense or a separate patch. A separate
> > > > patch would just remove make sure MTL does not touch the bits of
> > > > code Punit code. And the next patch would be the actual
> > > > squash_crawl-mid_cdclk_config patch.
> > >
> > >
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, November 14, 2022 4:01 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
>
> Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash when
> changing cdclk
>
> On Mon, Nov 14, 2022 at 03:14:33PM -0800, Srivatsa, Anusha wrote:
> ...
> > > > +static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > > + const struct intel_cdclk_config *cdclk_config,
> > > > + enum pipe pipe)
> > > > +{
> > > > + struct intel_cdclk_config mid_cdclk_config;
> > > > + int cdclk = cdclk_config->cdclk;
> > > > + int ret;
> > >
> > > You should initialize ret to 0 here since you don't set it in the
> > > new branch of the if/else ladder below.
> > >
> > > > +
> > > > + /* Inform power controller of upcoming frequency change. */
> > > > + if (DISPLAY_VER(dev_priv) >= 14) {
> > > > + /* DISPLAY14+ do not follow the PUnit mailbox
> > > communication,
> > >
> > > "Display versions 14 and above" or "Xe_LPD+ and beyond"
> > >
> > > Also, this is another case where "/*" should be on its own line.
> > >
> > > > +* skip this step.
> > > > +*/
> > > > + } else if (DISPLAY_VER(dev_priv) >= 11) {
> > > > + ret = skl_pcode_request(_priv->uncore,
> > > SKL_PCODE_CDCLK_CONTROL,
> > > > + SKL_CDCLK_PREPARE_FOR_CHANGE,
> > > > + SKL_CDCLK_READY_FOR_CHANGE,
> > > > + SKL_CDCLK_READY_FOR_CHANGE, 3);
> > > > } else {
> > > > /*
> > > > -* The timeout isn't specified, the 2ms used here is
> > > > based on
> > > > -* experiment.
> > > > -* FIXME: Waiting for the request completion could be
> > > delayed
> > > > -* until the next PCODE request based on BSpec.
> > > > +* BSpec requires us to wait up to 150usec, but that
> > > > leads to
> > > > +* timeouts; the 2ms used here is based on experiment.
> > > > */
> > > > ret = snb_pcode_write_timeout(_priv->uncore,
> > > >
> > > HSW_PCODE_DE_WRITE_FREQ_REQ,
> > > > -
> > > > cdclk_config->voltage_level,
> > > > - 150, 2);
> > > > + 0x8000, 150, 2);
> > >
> > > The switch from cdclk_config->voltage_level to a magic number
> > > (0x8000) on old platforms doesn't seem to be related to the rest
> > > of this patch. Ditto for the comment update about 150usec not being
> enough.
> > > Were those intended for a different patch?
> > Well, initially both squash and crawl support for MTl was the
> > intention. The change came to be a part of this patch because MTL
> > doesn't go through the Punit mailbox communication like previous
> > platforms and hence the churn. Thinking out loud if changing the
> > commit message makes more sense or a separate patch. A separate patch
> > would just remove make sure MTL does not touch the bits of code Punit
> > code. And the next patch would be the actual
> > squash_crawl-mid_cdclk_config patch.
>
> Okay, it looks like part of my confusion is just that the code movement made
> the diff deltas somewhat non-intuitive; due to code ordering changes, it's
> actually giving a diff of two completely different code blocks that just
> happen
> to look similar; you're not actually changing the value here.
>
> However I still think there might be a problem here. For pre-MTL platforms
> there are supposed to be two pcode transactions, one before the frequency
> change and one after. Before your patch, the 'before'
> transaction used a hardcoded 0x8000 and the 'after' transaction used
> cdclk_config->voltage_level [1]. Your patch keeps the 'before' step at the
> beginning of bxt_set_cdclk, but it seems to drop the 'after' step as far as I
> can
> see. I don't believe that was intentional was it?
That was not the intention here. I think the Pcode thing needs to be a separate
patch? Might make reviewing easy.
Anusha
>
> Matt
>
>
> [1] It looks like we might need some other updates to that pcode stuff in
> general for some pre-MTL platforms. What we have today doesn't match
> what I see on the bspec for TGL at least (bspec 49208). That would be work
> for a different series though; just figured I should mention it...
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, November 14, 2022 2:16 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
>
> Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash when
> changing cdclk
>
> On Mon, Nov 14, 2022 at 12:57:16PM -0800, Anusha Srivatsa wrote:
> > From: Ville Syrjälä
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > v4: Rebase
> > - Move checks to be more consistent (Ville)
> > - Add comments (Bala)
> > v5:
> > - Further small changes. Move checks around.
> > - Make if-else better looking (Ville)
> >
> > v6: MTl should not follow PUnit mailbox communication as the rest of
> > gen11+ platforms.(Anusha)
> >
> > v7: (MattR)
> > - s/cdclk_crawl_and_squash/cdclk_compute_crawl_squash_midpoint
> > - Cleanup Pcode checks in bxt_set_cdclk()
> > - Correct unsigned/signed checks
> >
> > Cc: Matt Roper
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 163
> > -
> > 1 file changed, 124 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 25d01271dc09..4db7103fe5d6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1727,37 +1727,74 @@ static bool cdclk_pll_is_unknown(unsigned int
> vco)
> > return vco == ~0;
> > }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > + return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_compute_crawl_and_squash_midpoint(struct
> drm_i915_private *i915,
> > + const struct
> intel_cdclk_config *old_cdclk_config,
> > + const struct
> intel_cdclk_config *new_cdclk_config,
> > + struct intel_cdclk_config
> *mid_cdclk_config) {
> > + u16 old_waveform, new_waveform, mid_waveform;
> > + int size = 16;
> > + int div = 2;
> > +
> > + /* Return if both Squash and Crawl are not present */
> > + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > + return false;
> > +
> > + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config-
> >cdclk);
> > +
> > + /* Return if Squash only or Crawl only is the desired action */
> > + if (old_cdclk_config->vco == 0 || new_cdclk_config->vco == 0 ||
> > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > + old_waveform == new_waveform)
> > + return false;
> > +
> > + *mid_cdclk_config = *new_cdclk_config;
> > +
> > + /* Populate the mid_cdclk_config accordingly.
>
> Nit: kernel coding style says the "/*" needs to be on its own line.
>
> > +* - If moving to a higher cdclk, the desired action is squashing.
> > +* The mid cdclk config should have the new (squash) waveform.
> > +* - If moving to a lower cdclk, the desired action is crawling.
> > +* The mid cdclk config should have the new vco.
> > +*/
> > +
> > + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> > + mid_cdclk_config->vco = old_cdclk_config->vco;
> > + mid_waveform = new_waveform;
> > + } else {
> > + mid_cdclk_config->vco = new_cdclk_config->vco;
> > + mid_waveform = old_waveform;
> >
Re: [Intel-gfx] [PATCH] drm/i915/display: Add missing checks for cdclk crawling
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, November 11, 2022 11:40 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Roper, Matthew D
>
> Subject: Re: [PATCH] drm/i915/display: Add missing checks for cdclk crawling
>
> On Fri, Nov 11, 2022 at 11:26:02AM -0800, Anusha Srivatsa wrote:
> > cdclk_sanitize() function was written assuming vco was a signed integer.
> > vco gets assigned to -1 (essentially ~0) for the case where PLL might
> > be enabled and vco is not a frequency that will ever get used. In such
> > a scenario the right thing to do is disable the PLL and re-enable it
> > again with a valid frequency.
> > However the vco is declared as a unsigned variable.
> > With the above assumption, driver takes crawl path when not needed.
> > Add explicit check to not crawl in the case of an invalid PLL.
> >
> > v2: Move the check from .h to .c (MattR)
> > - Move check to bxt_set_cdclk() instead of
> > intel_modeset_calc_cdclk() which is directly in the path of the
> > sanitize() function (Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Matt Roper
> > Suggested-by: Ville Syrjälä
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 8a9031012d74..2d9b7ba58358 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1716,6 +1716,16 @@ static void dg2_cdclk_squash_program(struct
> drm_i915_private *i915,
> > intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl); }
> >
> > +static bool cdclk_pll_is_unknown(unsigned int vco) {
> > + /*
> > +* Ensure driver does not take the crawl path for the
> > +* case when the vco is set to ~0 in the
> > +* sanitize path.
> > +*/
> > + return (vco == ~0);
>
> Pointless parens.
>
> > +}
> > +
> > static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > const struct intel_cdclk_config *cdclk_config,
> > enum pipe pipe)
> > @@ -1748,7 +1758,8 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> > return;
> > }
> >
> > - if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco
> > 0 && vco > 0) {
> > + if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco
> > 0 && vco > 0 &&
> > + (!cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco))) {
>
> More pointless parens
>
> With those removed
> Reviewed-by: Ville Syrjälä
Thanks Ville.
> Though I think we should probably add the pll_is_enabled() helper too, just
> make the code a bit more self explanatory.
At this point the current code should atleast not block the MTL cdclk churn
series. But the suggested helper will make the code more explanatory and I can
take it up.
Thanks for the feedback!
Anusha
> > if (dev_priv->display.cdclk.hw.vco != vco)
> > adlp_cdclk_pll_crawl(dev_priv, vco);
> > } else if (DISPLAY_VER(dev_priv) >= 11)
> > --
> > 2.25.1
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, November 9, 2022 3:30 AM
> To: Roper, Matthew D
> Cc: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org; Vivekanandan, Balasubramani
>
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and
> squash when changing cdclk
>
> On Tue, Nov 08, 2022 at 04:24:30PM -0800, Matt Roper wrote:
> > On Tue, Nov 08, 2022 at 03:56:23PM -0800, Srivatsa, Anusha wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Roper, Matthew D
> > > > Sent: Tuesday, November 8, 2022 3:43 PM
> > > > To: Srivatsa, Anusha
> > > > Cc: intel-gfx@lists.freedesktop.org; Vivekanandan, Balasubramani
> > > >
> > > > Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both
> > > > crawl and squash when changing cdclk
> > > >
> > > > On Fri, Nov 04, 2022 at 03:26:41PM -0700, Anusha Srivatsa wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > For MTL, changing cdclk from between certain frequencies has
> > > > > both squash and crawl. Use the current cdclk config and the
> > > > > new(desired) cdclk config to construtc a mid cdclk config.
> > > > > Set the cdclk twice:
> > > > > - Current cdclk -> mid cdclk
> > > > > - mid cdclk -> desired cdclk
> > > > >
> > > > > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
> > > > > change via modeset for platforms that support squash_crawl
> > > > > sequences(Ville)
> > > > >
> > > > > v3: Add checks for:
> > > > > - scenario where only slow clock is used and cdclk is actually 0
> > > > > (bringing up display).
> > > > > - PLLs are on before looking up the waveform.
> > > > > - Squash and crawl capability checks.(Ville)
> > > > >
> > > > > v4: Rebase
> > > > > - Move checks to be more consistent (Ville)
> > > > > - Add comments (Bala)
> > > > > v5:
> > > > > - Further small changes. Move checks around.
> > > > > - Make if-else better looking (Ville)
> > > > >
> > > > > v6: MTl should not follow PUnit mailbox communication as the
> > > > > rest of
> > > > > gen11+ platforms.(Anusha)
> > > > >
> > > > > Cc: Clint Taylor
> > > > > Cc: Balasubramani Vivekanandan
> > > >
> > > > > Signed-off-by: Anusha Srivatsa
> > > > > Signed-off-by: Ville Syrjälä
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 161
> > > > > +
> > > > > 1 file changed, 133 insertions(+), 28 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > index eada931cb1c8..d1e0763513be 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > @@ -1716,37 +1716,74 @@ static void
> > > > > dg2_cdclk_squash_program(struct
> > > > drm_i915_private *i915,
> > > > > intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl); }
> > > > >
> > > > > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > > > - const struct intel_cdclk_config *cdclk_config,
> > > > > - enum pipe pipe)
> > > > > +static int cdclk_squash_divider(u16 waveform) {
> > > > > + return hweight16(waveform ?: 0x); }
> > > > > +
> > > > > +static bool cdclk_crawl_and_squash(struct drm_i915_private
> > > > > +*i915,
> > > >
> > > > Bikeshed: maybe name this "cdclk_compute_crawl_squash_midpoint"
> > > > to help clarify that we're just computing stuff here and not
> > > > actually programming the hardware in this function?
> > > >
> > > > That naming would also help clarify why we're returning false if
> > > > we crawl but don't squash or vice versa (i.e., there's no midpoint in
> those cases).
> > >
> > > Makes sense.
> > >
> > > > > +const struct intel_cdclk_config
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, November 8, 2022 3:43 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Vivekanandan, Balasubramani
>
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and
> squash when changing cdclk
>
> On Fri, Nov 04, 2022 at 03:26:41PM -0700, Anusha Srivatsa wrote:
> > From: Ville Syrjälä
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > v4: Rebase
> > - Move checks to be more consistent (Ville)
> > - Add comments (Bala)
> > v5:
> > - Further small changes. Move checks around.
> > - Make if-else better looking (Ville)
> >
> > v6: MTl should not follow PUnit mailbox communication as the rest of
> > gen11+ platforms.(Anusha)
> >
> > Cc: Clint Taylor
> > Cc: Balasubramani Vivekanandan
>
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 161
> > +
> > 1 file changed, 133 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index eada931cb1c8..d1e0763513be 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1716,37 +1716,74 @@ static void dg2_cdclk_squash_program(struct
> drm_i915_private *i915,
> > intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl); }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > + return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,
>
> Bikeshed: maybe name this "cdclk_compute_crawl_squash_midpoint" to
> help clarify that we're just computing stuff here and not actually
> programming the hardware in this function?
>
> That naming would also help clarify why we're returning false if we crawl but
> don't squash or vice versa (i.e., there's no midpoint in those cases).
Makes sense.
> > + const struct intel_cdclk_config
> *old_cdclk_config,
> > + const struct intel_cdclk_config
> *new_cdclk_config,
> > + struct intel_cdclk_config *mid_cdclk_config)
> {
> > + u16 old_waveform, new_waveform, mid_waveform;
> > + int size = 16;
> > + int div = 2;
> > +
> > + /* Return if both Squash and Crawl are not present */
> > + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > + return false;
> > +
> > + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config-
> >cdclk);
> > +
> > + /* Return if Squash only or Crawl only is the desired action */
> > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
>
> Isn't vco unsigned? "== 0" should be fine here I think.
You mean the new_cdclk_config->vco right?
> > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > + old_waveform == new_waveform)
> > + return false;
> > +
> > + *mid_cdclk_config = *new_cdclk_config;
> > +
> > + /* Populate the mid_cdclk_config accordingly.
> > +* - If moving to a higher cdclk, the desired action is squashing.
> > +* The mid cdclk config should have the new (squash) waveform.
> > +* - If moving to a lower cdclk, the desired action is crawling.
> > +* The mid cdclk config should have the new vco.
> > +*/
> > +
> > + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> > +
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, October 28, 2022 2:05 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Vivekanandan, Balasubramani
>
> Subject: Re: [PATCH 1/2] drm/i915/display: Do both crawl and squash when
> changing cdclk
>
> On Wed, Oct 26, 2022 at 04:22:56PM -0700, Anusha Srivatsa wrote:
> > From: Ville Syrjälä
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > v4: Rebase
> > - Move checks to be more consistent (Ville)
> > - Add comments (Bala)
> >
> > Cc: Balasubramani Vivekanandan
>
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 157
> > +
> > 1 file changed, 129 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index eada931cb1c8..6a775367f02a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1716,37 +1716,74 @@ static void dg2_cdclk_squash_program(struct
> drm_i915_private *i915,
> > intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl); }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > + return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,
> > + const struct intel_cdclk_config
> *old_cdclk_config,
> > + const struct intel_cdclk_config
> *new_cdclk_config,
> > + struct intel_cdclk_config *mid_cdclk_config)
> {
> > + u16 old_waveform, new_waveform, mid_waveform;
> > + int size = 16;
> > + int div = 2;
> > +
> > + /* Return if both Squash and Crawl are not present */
> > + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > + return false;
> > +
> > + /* Return if Squash only or Crawl only is the desired action */
> > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
> > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > + old_waveform == new_waveform)
>
> Those are not yet initialized.
*facepalm*
> > + return false;
> > +
> > + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config-
> >cdclk);
> > +
> > + *mid_cdclk_config = *new_cdclk_config;
> > +
> > + /* Populate the mid_cdclk_config accordingly.
> > +* - If moving to a higher cdclk, the desired action is squashing.
> > +* The mid cdclk config should have the new (squash) waveform.
> > +* - If moving to a lower cdclk, the desired action is crawling.
> > +* The mid cdclk config should have the new vco.
> > +*/
> > +
> > + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> > + mid_cdclk_config->vco = old_cdclk_config->vco;
> > + mid_waveform = new_waveform;
> > + } else {
> > + mid_cdclk_config->vco = new_cdclk_config->vco;
> > + mid_waveform = old_waveform;
> > + }
> > +
> > + mid_cdclk_config->cdclk =
> DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
> > + mid_cdclk_config->vco, size
> * div);
> > +
> > + /* make sure the mid clock came out sane */
> > +
> > + drm_WARN_ON(>drm, mid_cdclk_config->cdclk <
> > + min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
> > + d
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915/display: Change terminology for cdclk actions
From: Patchwork
Sent: Wednesday, October 26, 2022 10:07 AM
To: Srivatsa, Anusha
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for series starting with [CI,1/4]
drm/i915/display: Change terminology for cdclk actions
Patch Details
Series:
series starting with [CI,1/4] drm/i915/display: Change terminology for cdclk
actions
URL:
https://patchwork.freedesktop.org/series/110145/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110145v1/index.html
CI Bug Log - changes from CI_DRM_12295_full -> Patchwork_110145v1_full
Summary
FAILURE
Serious unknown changes coming with Patchwork_110145v1_full absolutely need to
be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110145v1_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (9 -> 11)
Additional (2): shard-rkl shard-dg1
Possible new issues
Here are the unknown changes that may have been introduced in
Patchwork_110145v1_full:
IGT changes
Possible regressions
* igt@i915_pm_rpm@system-suspend-execbuf:
* shard-iclb:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-iclb6/igt@i915_pm_...@system-suspend-execbuf.html>
->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110145v1/shard-iclb8/igt@i915_pm_...@system-suspend-execbuf.html>
* igt@kms_async_flips@async-flip-with-page-flip-events@pipe-b-edp-1:
* shard-skl:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-skl1/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-b-edp-1.html>
->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110145v1/shard-skl3/igt@kms_async_flips@async-flip-with-page-flip-eve...@pipe-b-edp-1.html>
Checked the igt-runner and dmesg logs for both the above failures. It shows all
129/129 tests to be passing. Dmesg looks clean as well.
Anusha
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@sysfs_timeslice_duration@idempotent@vcs0:
* {shard-dg1}: NOTRUN ->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110145v1/shard-dg1-19/igt@sysfs_timeslice_duration@idempot...@vcs0.html>
+9 similar issues
Known issues
Here are the changes found in Patchwork_110145v1_full that come from known
issues:
CI changes
Issues hit
* boot:
* shard-glk:
(PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk9/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk9/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk9/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk9/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk8/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk8/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk8/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk7/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk7/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk7/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk6/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk6/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk6/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk5/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk5/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk5/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk3/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk3/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk3/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk2/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk2/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk2/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk1/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk1/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12295/shard-glk1/boot.html>)
->
(PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110145v1/shard-glk7/boot.html>,
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110145v1/shard-glk7/boot.html>,
PASS<
Re: [Intel-gfx] [CI 1/4] drm/i915/display: Change terminology for cdclk actions
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, October 26, 2022 12:52 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [CI 1/4] drm/i915/display: Change terminology for
> cdclk actions
>
> On Tue, 25 Oct 2022, Anusha Srivatsa wrote:
> > No functional changes. Changing terminology in some print statements.
> > s/has_cdclk_squasher/has_cdclk_squash,
> > s/crawler/crawl and s/squasher/squash.
>
> Any particular reason you re-sent this for CI? You know you can re-run tests
> from the patchwork page if the patches remain unchanged?
Checkpatch return some errors on the previous series:
https://patchwork.freedesktop.org/series/110135/
Had to rectify them and send it again.
Anusha
> BR,
> Jani.
>
>
> >
> > Cc: Balasubramani Vivekanandan
>
> > Cc: Ville Syrjälä
> > Signed-off-by: Anusha Srivatsa
> > Reviewed-by: Balasubramani Vivekanandan
> >
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index ad401357ab66..0f5add2fc51b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1220,7 +1220,7 @@ static void skl_cdclk_uninit_hw(struct
> drm_i915_private *dev_priv)
> > skl_set_cdclk(dev_priv, _config, INVALID_PIPE); }
> >
> > -static bool has_cdclk_squasher(struct drm_i915_private *i915)
> > +static bool has_cdclk_squash(struct drm_i915_private *i915)
> > {
> > return IS_DG2(i915);
> > }
> > @@ -1520,7 +1520,7 @@ static void bxt_get_cdclk(struct drm_i915_private
> *dev_priv,
> > return;
> > }
> >
> > - if (has_cdclk_squasher(dev_priv))
> > + if (has_cdclk_squash(dev_priv))
> > squash_ctl = intel_de_read(dev_priv, CDCLK_SQUASH_CTL);
> >
> > if (squash_ctl & CDCLK_SQUASH_ENABLE) { @@ -1747,7 +1747,7 @@
> static
> > void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > else
> > clock = cdclk;
> >
> > - if (has_cdclk_squasher(dev_priv)) {
> > + if (has_cdclk_squash(dev_priv)) {
> > u32 squash_ctl = 0;
> >
> > if (waveform)
> > @@ -1845,7 +1845,7 @@ static void bxt_sanitize_cdclk(struct
> drm_i915_private *dev_priv)
> > expected = skl_cdclk_decimal(cdclk);
> >
> > /* Figure out what CD2X divider we should be using for this cdclk */
> > - if (has_cdclk_squasher(dev_priv))
> > + if (has_cdclk_squash(dev_priv))
> > clock = dev_priv->display.cdclk.hw.vco / 2;
> > else
> > clock = dev_priv->display.cdclk.hw.cdclk; @@ -1976,7
> +1976,7 @@
> > static bool intel_cdclk_can_squash(struct drm_i915_private *dev_priv,
> > * the moment all platforms with squasher use a fixed cd2x
> > * divider.
> > */
> > - if (!has_cdclk_squasher(dev_priv))
> > + if (!has_cdclk_squash(dev_priv))
> > return false;
> >
> > return a->cdclk != b->cdclk &&
> > @@ -2028,7 +2028,7 @@ static bool intel_cdclk_can_cd2x_update(struct
> drm_i915_private *dev_priv,
> > * the moment all platforms with squasher use a fixed cd2x
> > * divider.
> > */
> > - if (has_cdclk_squasher(dev_priv))
> > + if (has_cdclk_squash(dev_priv))
> > return false;
> >
> > return a->cdclk != b->cdclk &&
> > @@ -2754,12 +2754,12 @@ int intel_modeset_calc_cdclk(struct
> intel_atomic_state *state)
> >_cdclk_state->actual,
> >_cdclk_state->actual)) {
> > drm_dbg_kms(_priv->drm,
> > - "Can change cdclk via squasher\n");
> > + "Can change cdclk via squashing\n");
> > } else if (intel_cdclk_can_crawl(dev_priv,
> > _cdclk_state->actual,
> > _cdclk_state->actual)) {
> > drm_dbg_kms(_priv->drm,
> > - "Can change cdclk via crawl\n");
> > + "Can change cdclk via crawling\n");
> > } else if (pipe != INVALID_PIPE) {
> > new_cdclk_state->pipe = pipe;
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 4/4] drm/i915/display: Move squash_ctl register programming to its own function
> -Original Message-
> From: Vivekanandan, Balasubramani
>
> Sent: Friday, October 21, 2022 12:08 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Cc: Ville Syrjälä
> Subject: Re: [PATCH 4/4] drm/i915/display: Move squash_ctl register
> programming to its own function
>
> On 20.10.2022 17:20, Anusha Srivatsa wrote:
> > No functional change. Introduce dg2_cdclk_squash_programming and
> move
> > squash_ctl register programming bits to this.
> >
> > Cc: Balasubramani Vivekanandan
>
> > Cc: Ville Syrjälä
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 23
> > +-
> > 1 file changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 8701796788e3..b692186c8f02 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1705,6 +1705,18 @@ static void bxt_cdclk_pll(struct
> > drm_i915_private *i915, int vco)
> >
> > }
> >
> > +static void dg2_cdclk_squash_programming(struct drm_i915_private
> *i915,
> > +u16 waveform)
> > +{
> > + u32 squash_ctl = 0;
> > +
> > + if (waveform)
> > + squash_ctl = CDCLK_SQUASH_ENABLE |
> > +CDCLK_SQUASH_WINDOW_SIZE(0xf) | waveform;
> > +
> > + intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl); }
> > +
> > static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > const struct intel_cdclk_config *cdclk_config,
> > enum pipe pipe)
> > @@ -1752,15 +1764,8 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> > else
> > clock = cdclk;
> >
> > - if (HAS_CDCLK_SQUASH(dev_priv)) {
> > - u32 squash_ctl = 0;
> > -
> > - if (waveform)
> > - squash_ctl = CDCLK_SQUASH_ENABLE |
> > - CDCLK_SQUASH_WINDOW_SIZE(0xf) |
> waveform;
> > -
> > - intel_de_write(dev_priv, CDCLK_SQUASH_CTL, squash_ctl);
> > - }
> > + if (HAS_CDCLK_SQUASH(dev_priv))
> > + dg2_cdclk_squash_programming(dev_priv, waveform);
>
> Is it possible to move also the function cdclk_squash_waveform() inside
> dg2_cdclk_squash_programming()?
Hmmm. Are you thinking it is better to have both grabbing the squash waveform
and programming the squash_ctl registers in one place better? IMO the fact that
they are separate makes it more readable. We will have to return waveform and
calculate the clock anyway
Anusha
> Regards,
> Bala
>
> >
> > val = bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) |
> > bxt_cdclk_cd2x_pipe(dev_priv, pipe) |
> > --
> > 2.25.1
> >
Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Move chunks of code out of bxt_set_cdclk()
> -Original Message-
> From: Jani Nikula
> Sent: Friday, October 21, 2022 1:32 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Cc: Vivekanandan, Balasubramani
>
> Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Move chunks of code
> out of bxt_set_cdclk()
>
> On Thu, 20 Oct 2022, Anusha Srivatsa wrote:
> > No functional change. Moving segments out to simplify
> > bxt_set_cdlck()
> >
> > Cc: Balasubramani Vivekanandan
>
> > Cc: Ville Syrjälä
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 40
> > ++
> > 1 file changed, 25 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 45babbc6290f..8701796788e3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1684,6 +1684,27 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
> > return 0x;
> > }
> >
> > +static void icl_cdclk_pll(struct drm_i915_private *i915, int vco)
>
> The function name reads like it leaves something hanging in the air.
>
> icl cdclk pll *what*?
>
> Maybe update?
s/ icl_cdclk_pll/ icl_cdclk_pll_update.
Will make this ichange.
Thanks,
Anusha
> BR,
> Jani.
>
> > +{
> > + if (i915->display.cdclk.hw.vco != 0 &&
> > + i915->display.cdclk.hw.vco != vco)
> > + icl_cdclk_pll_disable(i915);
> > +
> > + if (i915->display.cdclk.hw.vco != vco)
> > + icl_cdclk_pll_enable(i915, vco);
> > +}
> > +
> > +static void bxt_cdclk_pll(struct drm_i915_private *i915, int vco) {
> > + if (i915->display.cdclk.hw.vco != 0 &&
> > + i915->display.cdclk.hw.vco != vco)
> > + bxt_de_pll_disable(i915);
> > +
> > + if (i915->display.cdclk.hw.vco != vco)
> > + bxt_de_pll_enable(i915, vco);
> > +
> > +}
> > +
> > static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > const struct intel_cdclk_config *cdclk_config,
> > enum pipe pipe)
> > @@ -1719,21 +1740,10 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> > if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco
> > 0 && vco > 0) {
> > if (dev_priv->display.cdclk.hw.vco != vco)
> > adlp_cdclk_pll_crawl(dev_priv, vco);
> > - } else if (DISPLAY_VER(dev_priv) >= 11) {
> > - if (dev_priv->display.cdclk.hw.vco != 0 &&
> > - dev_priv->display.cdclk.hw.vco != vco)
> > - icl_cdclk_pll_disable(dev_priv);
> > -
> > - if (dev_priv->display.cdclk.hw.vco != vco)
> > - icl_cdclk_pll_enable(dev_priv, vco);
> > - } else {
> > - if (dev_priv->display.cdclk.hw.vco != 0 &&
> > - dev_priv->display.cdclk.hw.vco != vco)
> > - bxt_de_pll_disable(dev_priv);
> > -
> > - if (dev_priv->display.cdclk.hw.vco != vco)
> > - bxt_de_pll_enable(dev_priv, vco);
> > - }
> > + } else if (DISPLAY_VER(dev_priv) >= 11)
> > + icl_cdclk_pll(dev_priv, vco);
> > + else
> > + bxt_cdclk_pll(dev_priv, vco);
> >
> > waveform = cdclk_squash_waveform(dev_priv, cdclk);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 4/4] drm/i915/display: Move squash_ctl register programming to its own function
> -Original Message-
> From: Jani Nikula
> Sent: Friday, October 21, 2022 1:41 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Cc: Vivekanandan, Balasubramani
>
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/display: Move squash_ctl
> register programming to its own function
>
> On Thu, 20 Oct 2022, Anusha Srivatsa wrote:
> > No functional change. Introduce dg2_cdclk_squash_programming and
> move
> > squash_ctl register programming bits to this.
> >
> > Cc: Balasubramani Vivekanandan
>
> > Cc: Ville Syrjälä
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 23
> > +-
> > 1 file changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 8701796788e3..b692186c8f02 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1705,6 +1705,18 @@ static void bxt_cdclk_pll(struct
> > drm_i915_private *i915, int vco)
> >
> > }
> >
> > +static void dg2_cdclk_squash_programming(struct drm_i915_private
> *i915,
> > +u16 waveform)
>
> Function names that are verbs should preferrably use the imperative mood,
> i.e. program() instead of programmed(), programs() or programming().
>
> I'm also not sure "programming" or "program" is a very descriptive thing;
> almost everything here is about "programming" something or other.
Makes sense. Didn’t have a good feeling about the name in the first place.
Thanks for the validation.
Anusha
> BR,
> Jani.
>
>
> > +{
> > + u32 squash_ctl = 0;
> > +
> > + if (waveform)
> > + squash_ctl = CDCLK_SQUASH_ENABLE |
> > +CDCLK_SQUASH_WINDOW_SIZE(0xf) | waveform;
> > +
> > + intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl); }
> > +
> > static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > const struct intel_cdclk_config *cdclk_config,
> > enum pipe pipe)
> > @@ -1752,15 +1764,8 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> > else
> > clock = cdclk;
> >
> > - if (HAS_CDCLK_SQUASH(dev_priv)) {
> > - u32 squash_ctl = 0;
> > -
> > - if (waveform)
> > - squash_ctl = CDCLK_SQUASH_ENABLE |
> > - CDCLK_SQUASH_WINDOW_SIZE(0xf) |
> waveform;
> > -
> > - intel_de_write(dev_priv, CDCLK_SQUASH_CTL, squash_ctl);
> > - }
> > + if (HAS_CDCLK_SQUASH(dev_priv))
> > + dg2_cdclk_squash_programming(dev_priv, waveform);
> >
> > val = bxt_cdclk_cd2x_div_sel(dev_priv, clock, vco) |
> > bxt_cdclk_cd2x_pipe(dev_priv, pipe) |
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/4] drm/i915/display: Introduce HAS_CDCLK_SQUASH macro
> -Original Message-
> From: Jani Nikula
> Sent: Friday, October 21, 2022 1:47 AM
> To: Vivekanandan, Balasubramani
> ; Srivatsa, Anusha
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915/display: Introduce
> HAS_CDCLK_SQUASH macro
>
> On Fri, 21 Oct 2022, Balasubramani Vivekanandan
> wrote:
> > On 20.10.2022 17:20, Anusha Srivatsa wrote:
> >> Driver had discrepancy in how cdclk squash and crawl support were
> >> checked. Like crawl, add squash as a 1 bit feature flag to the
> >> display section of DG2.
> >>
> >> Cc: Balasubramani Vivekanandan
>
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Anusha Srivatsa
> >> ---
> >> drivers/gpu/drm/i915/display/intel_cdclk.c | 15 +--
> >> drivers/gpu/drm/i915/i915_drv.h| 1 +
> >> drivers/gpu/drm/i915/i915_pci.c| 1 +
> >> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> >> 4 files changed, 8 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> index 0f5add2fc51b..45babbc6290f 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> >> @@ -1220,11 +1220,6 @@ static void skl_cdclk_uninit_hw(struct
> drm_i915_private *dev_priv)
> >>skl_set_cdclk(dev_priv, _config, INVALID_PIPE); }
> >>
> >> -static bool has_cdclk_squash(struct drm_i915_private *i915) -{
> >> - return IS_DG2(i915);
> >> -}
> >> -
> >> struct intel_cdclk_vals {
> >>u32 cdclk;
> >>u16 refclk;
> >> @@ -1520,7 +1515,7 @@ static void bxt_get_cdclk(struct
> drm_i915_private *dev_priv,
> >>return;
> >>}
> >>
> >> - if (has_cdclk_squash(dev_priv))
> >> + if (HAS_CDCLK_SQUASH(dev_priv))
> >>squash_ctl = intel_de_read(dev_priv, CDCLK_SQUASH_CTL);
> >>
> >>if (squash_ctl & CDCLK_SQUASH_ENABLE) { @@ -1747,7 +1742,7 @@
> >> static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> >>else
> >>clock = cdclk;
> >>
> >> - if (has_cdclk_squash(dev_priv)) {
> >> + if (HAS_CDCLK_SQUASH(dev_priv)) {
> >>u32 squash_ctl = 0;
> >>
> >>if (waveform)
> >> @@ -1845,7 +1840,7 @@ static void bxt_sanitize_cdclk(struct
> drm_i915_private *dev_priv)
> >>expected = skl_cdclk_decimal(cdclk);
> >>
> >>/* Figure out what CD2X divider we should be using for this cdclk */
> >> - if (has_cdclk_squash(dev_priv))
> >> + if (HAS_CDCLK_SQUASH(dev_priv))
> >>clock = dev_priv->display.cdclk.hw.vco / 2;
> >>else
> >>clock = dev_priv->display.cdclk.hw.cdclk; @@ -1976,7
> +1971,7 @@
> >> static bool intel_cdclk_can_squash(struct drm_i915_private *dev_priv,
> >> * the moment all platforms with squasher use a fixed cd2x
> >> * divider.
> >> */
> >> - if (!has_cdclk_squash(dev_priv))
> >> + if (!HAS_CDCLK_SQUASH(dev_priv))
> >>return false;
> >>
> >>return a->cdclk != b->cdclk &&
> >> @@ -2028,7 +2023,7 @@ static bool intel_cdclk_can_cd2x_update(struct
> drm_i915_private *dev_priv,
> >> * the moment all platforms with squasher use a fixed cd2x
> >> * divider.
> >> */
> >> - if (has_cdclk_squash(dev_priv))
> >> + if (HAS_CDCLK_SQUASH(dev_priv))
> >>return false;
> >>
> >>return a->cdclk != b->cdclk &&
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h index d7b8eb9d4117..db51050e3ba2
> >> 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -869,6 +869,7 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> >> #define HAS_DOUBLE_BUFFERED_M_N(dev_priv)
> (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
> >>
> >> #define HAS_CDCLK_CRAWL(dev_priv) (INTEL_INFO(dev_priv)-
> >display.has_cdclk_crawl)
> >> +#define HAS_CDCLK_SQUASH(dev_priv) (INTEL_INFO(dev_priv)-
> >display.has_cdclk_squash)
> >> #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)-
> >display.has_ddi)
> >> #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(d
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, October 20, 2022 8:15 AM
> To: Vivekanandan, Balasubramani
>
> Cc: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and
> squash when changing cdclk
>
> On Thu, Oct 20, 2022 at 08:12:04PM +0530, Balasubramani Vivekanandan
> wrote:
> > On 13.10.2022 16:32, Anusha Srivatsa wrote:
> > > From: Ville Syrjälä
> > >
> > > For MTL, changing cdclk from between certain frequencies has both
> > > squash and crawl. Use the current cdclk config and the new(desired)
> > > cdclk config to construtc a mid cdclk config.
> > > Set the cdclk twice:
> > > - Current cdclk -> mid cdclk
> > > - mid cdclk -> desired cdclk
> > >
> > > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change
> > > via modeset for platforms that support squash_crawl sequences(Ville)
> > >
> > > v3: Add checks for:
> > > - scenario where only slow clock is used and cdclk is actually 0
> > > (bringing up display).
> > > - PLLs are on before looking up the waveform.
> > > - Squash and crawl capability checks.(Ville)
> > >
> > > Signed-off-by: Anusha Srivatsa
> > > Signed-off-by: Ville Syrjälä
> >
> > Please add the Bspec number.
> >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 157
> > > +
> > > 1 file changed, 128 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index ad401357ab66..430b4cb0a8ab 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1675,7 +1675,7 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
> > > const struct intel_cdclk_vals *table = dev_priv->display.cdclk.table;
> > > int i;
> > >
> > > - if (cdclk == dev_priv->display.cdclk.hw.bypass)
> > > + if (cdclk == dev_priv->display.cdclk.hw.bypass || cdclk == 0)
> > > return 0;
> > >
> > > for (i = 0; table[i].refclk; i++)
> > > @@ -1689,37 +1689,72 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
> > > return 0x;
> > > }
> > >
> > > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > - const struct intel_cdclk_config *cdclk_config,
> > > - enum pipe pipe)
> > > +static int cdclk_squash_divider(u16 waveform) {
> > > + return hweight16(waveform ?: 0x); }
> > > +
> > > +static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,
> > > +const struct intel_cdclk_config
> *old_cdclk_config,
> > > +const struct intel_cdclk_config
> *new_cdclk_config,
> > > +struct intel_cdclk_config *mid_cdclk_config)
> {
> >
> > I was thinking of asking to rename this function to a more descriptive
> > one, but then I myself was not able to come up with one.
> > For a fresh eyes, it is difficult to make out what this function is
> > actually doing. Can you please add a summary as a comment above this
> > function pointing out what is mid_cdclk and whats the meaning of its
> > return value.
> >
> > > + u16 old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > > + u16 new_waveform = cdclk_squash_waveform(i915,
> new_cdclk_config->cdclk);
> > > + u16 mid_waveform;
> > > + int size = 16;
> > > + int div = 2;
> > > +
> > > + /* Return if both Squash and Crawl are not present */
> > > + if (!HAS_CDCLK_CRAWL(i915) || !has_cdclk_squasher(i915))
> > > + return false;
> >
> > Can cdclk_squasher feature availability be also made a part of
> > device_info structure like cdclk_crawl and create a macro similar to
> > HAS_CDCLK_CRAWL?
> > Like Ville said it looks bit weird. Also we would avoid adding
> > platform checks inside has_cdclk_squasher() function like it is done
> > now in your second patch.
> >
> > > +
> > > + /* Return if Squash only or Crawl only is the desired action */
> > > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
> > > + old_cdclk_config->vco == new_cdclk_config->
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Vivekanandan, Balasubramani
>
> Sent: Thursday, October 20, 2022 7:42 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and
> squash when changing cdclk
>
> On 13.10.2022 16:32, Anusha Srivatsa wrote:
> > From: Ville Syrjälä
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Ville Syrjälä
>
> Please add the Bspec number.
Will do.
>
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 157
> > +
> > 1 file changed, 128 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index ad401357ab66..430b4cb0a8ab 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1675,7 +1675,7 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
> > const struct intel_cdclk_vals *table = dev_priv->display.cdclk.table;
> > int i;
> >
> > - if (cdclk == dev_priv->display.cdclk.hw.bypass)
> > + if (cdclk == dev_priv->display.cdclk.hw.bypass || cdclk == 0)
> > return 0;
> >
> > for (i = 0; table[i].refclk; i++)
> > @@ -1689,37 +1689,72 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
> > return 0x;
> > }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > + return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,
> > + const struct intel_cdclk_config
> *old_cdclk_config,
> > + const struct intel_cdclk_config
> *new_cdclk_config,
> > + struct intel_cdclk_config *mid_cdclk_config)
> {
>
> I was thinking of asking to rename this function to a more descriptive one,
> but then I myself was not able to come up with one.
> For a fresh eyes, it is difficult to make out what this function is actually
> doing.
> Can you please add a summary as a comment above this function pointing
> out what is mid_cdclk and whats the meaning of its return value.
I thought the commit message was explaining the needful. But I agree if it is
indeed confusing, adding comments in code would help, will churn that change.
>
> > + u16 old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > + u16 new_waveform = cdclk_squash_waveform(i915,
> new_cdclk_config->cdclk);
> > + u16 mid_waveform;
> > + int size = 16;
> > + int div = 2;
> > +
> > + /* Return if both Squash and Crawl are not present */
> > + if (!HAS_CDCLK_CRAWL(i915) || !has_cdclk_squasher(i915))
> > + return false;
>
> Can cdclk_squasher feature availability be also made a part of device_info
> structure like cdclk_crawl and create a macro similar to HAS_CDCLK_CRAWL?
> Like Ville said it looks bit weird. Also we would avoid adding platform checks
> inside has_cdclk_squasher() function like it is done now in your second
> patch.
Yes will make that change.
>
> > +
> > + /* Return if Squash only or Crawl only is the desired action */
> > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
> > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > + old_waveform == new_waveform)
> > + return false;
> > +
> > + *mid_cdclk_config = *new_cdclk_config;
> > +
> > + /* If moving to a higher cdclk(squash) the mid cdclk config
> > +* sho
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, October 20, 2022 4:33 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/2] drm/i915/display: Do both crawl and squash when
> changing cdclk
>
> On Thu, Oct 13, 2022 at 04:32:22PM -0700, Anusha Srivatsa wrote:
> > From: Ville Syrjälä
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 157
> > +
> > 1 file changed, 128 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index ad401357ab66..430b4cb0a8ab 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1675,7 +1675,7 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
> > const struct intel_cdclk_vals *table = dev_priv->display.cdclk.table;
> > int i;
> >
> > - if (cdclk == dev_priv->display.cdclk.hw.bypass)
> > + if (cdclk == dev_priv->display.cdclk.hw.bypass || cdclk == 0)
>
> cdclk should never be zero. Why is that needed? Hmm. Ah, we do set it to
> zero during sanitation. But that shouldn't matter since we shouldn't call this
> in that case...
>
> > return 0;
> >
> > for (i = 0; table[i].refclk; i++)
> > @@ -1689,37 +1689,72 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
> > return 0x;
> > }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > + return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_crawl_and_squash(struct drm_i915_private *i915,
> > + const struct intel_cdclk_config
> *old_cdclk_config,
> > + const struct intel_cdclk_config
> *new_cdclk_config,
> > + struct intel_cdclk_config *mid_cdclk_config)
> {
> > + u16 old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > + u16 new_waveform = cdclk_squash_waveform(i915,
> > +new_cdclk_config->cdclk);
>
> ... but here we do call it. Just moving these to be called after the vco
> checks
> should take care of that issue.
Ok. Makes sense.
> > + u16 mid_waveform;
> > + int size = 16;
> > + int div = 2;
> > +
> > + /* Return if both Squash and Crawl are not present */
> > + if (!HAS_CDCLK_CRAWL(i915) || !has_cdclk_squasher(i915))
> > + return false;
> > +
> > + /* Return if Squash only or Crawl only is the desired action */
> > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
> > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > + old_waveform == new_waveform)
> > + return false;
> > +
> > + *mid_cdclk_config = *new_cdclk_config;
> > +
> > + /* If moving to a higher cdclk(squash) the mid cdclk config
> > +* should have the new (squash) waveform.
> > +* If moving to a lower cdclk (crawl) the mid cdclk config
> > +* should have the new vco.
> > +*/
> > +
> > + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> > + mid_cdclk_config->vco = old_cdclk_config->vco;
> > + mid_waveform = new_waveform;
> > + } else {
> > + mid_cdclk_config->vco = new_cdclk_config->vco;
> > + mid_waveform = old_waveform;
> > + }
> > +
> > + mid_cdclk_config->cdclk =
> DIV_ROUND_CLO
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk
From: Patchwork Sent: Thursday, October 13, 2022 9:57 PM To: Srivatsa, Anusha Cc: intel-gfx@lists.freedesktop.org Subject: ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk Patch Details Series: series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk URL: https://patchwork.freedesktop.org/series/109694/ State: failure Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/index.html CI Bug Log - changes from CI_DRM_12242_full -> Patchwork_109694v1_full Summary FAILURE Serious unknown changes coming with Patchwork_109694v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109694v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 11) Additional (2): shard-rkl shard-dg1 Possible new issues Here are the unknown changes that may have been introduced in Patchwork_109694v1_full: IGT changes Possible regressions * igt@syncobj_wait@wait-any-snapshot: * shard-skl: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-skl9/igt@syncobj_w...@wait-any-snapshot.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-skl4/igt@syncobj_w...@wait-any-snapshot.html> Failure not related to the changes introduced in this series. Anusha Known issues Here are the changes found in Patchwork_109694v1_full that come from known issues: CI changes Issues hit * boot: * shard-glk: (PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk1/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk1/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk1/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk2/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk2/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk2/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk2/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk3/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk3/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk3/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk5/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk5/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk5/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk6/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk6/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk6/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk7/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk7/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk8/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk8/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk8/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk8/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk9/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk9/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12242/shard-glk9/boot.html>) -> (PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk9/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk9/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk9/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk8/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk8/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk8/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk7/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk7/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk7/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk6/boot.html>, PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109694v1/shard-glk6/bo
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk
@ville.syrj...@linux.intel.com<mailto:ville.syrj...@linux.intel.com> The mid_cdclk_config logic actually showing issues during cdclk sanitize “cdclk 0 not valid for refclk abc” Though that part logic should not be affected….. Looking into it. Anusha From: Patchwork Sent: Friday, September 30, 2022 3:25 PM To: Srivatsa, Anusha Cc: intel-gfx@lists.freedesktop.org Subject: ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk Patch Details Series: series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk URL: https://patchwork.freedesktop.org/series/109326/ State: failure Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/index.html CI Bug Log - changes from CI_DRM_12204 -> Patchwork_109326v1 Summary FAILURE Serious unknown changes coming with Patchwork_109326v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_109326v1, please notify your bug team 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_109326v1/index.html Participating hosts (48 -> 48) Additional (4): bat-dg2-11 fi-rkl-11600 bat-adls-5 fi-tgl-dsi Missing (4): fi-ctg-p8600 fi-icl-u2 fi-bdw-samus fi-hsw-4200u Possible new issues Here are the unknown changes that may have been introduced in Patchwork_109326v1: IGT changes Possible regressions * igt@gem_close_race@basic-threads: * fi-snb-2600: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-snb-2600/igt@gem_close_r...@basic-threads.html> -> DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-snb-2600/igt@gem_close_r...@basic-threads.html> * igt@i915_hangman@error-state-basic: * fi-blb-e6850: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-blb-e6850/igt@i915_hang...@error-state-basic.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-blb-e6850/igt@i915_hang...@error-state-basic.html> * fi-pnv-d510: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-pnv-d510/igt@i915_hang...@error-state-basic.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-pnv-d510/igt@i915_hang...@error-state-basic.html> * igt@i915_module_load@load: * fi-skl-6700k2: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-skl-6700k2/igt@i915_module_l...@load.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-skl-6700k2/igt@i915_module_l...@load.html> * fi-cfl-guc: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-cfl-guc/igt@i915_module_l...@load.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-cfl-guc/igt@i915_module_l...@load.html> * fi-bdw-5557u: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-bdw-5557u/igt@i915_module_l...@load.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-bdw-5557u/igt@i915_module_l...@load.html> * fi-cfl-8109u: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-cfl-8109u/igt@i915_module_l...@load.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-cfl-8109u/igt@i915_module_l...@load.html> * fi-ilk-650: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-ilk-650/igt@i915_module_l...@load.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-ilk-650/igt@i915_module_l...@load.html> * fi-bsw-kefka: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-bsw-kefka/igt@i915_module_l...@load.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-bsw-kefka/igt@i915_module_l...@load.html> * igt@i915_pm_rpm@basic-pci-d3-state: * fi-adl-ddr5: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-adl-ddr5/igt@i915_pm_...@basic-pci-d3-state.html> -> DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-adl-ddr5/igt@i915_pm_...@basic-pci-d3-state.html> * fi-rkl-guc: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/fi-rkl-guc/igt@i915_pm_...@basic-pci-d3-state.html> -> DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/fi-rkl-guc/igt@i915_pm_...@basic-pci-d3-state.html> * bat-adlp-4: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12204/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html> -> DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109326v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html> * fi-tgl-u2: PASS<https://
Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Add CDCLK Support for MTL
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, September 28, 2022 12:24 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Add CDCLK Support for
> MTL
>
> On Wed, Sep 28, 2022 at 12:04:15PM -0700, Anusha Srivatsa wrote:
> > As per bSpec MTL has 38.4 MHz Reference clock.
> > MTL does support squasher like DG2 but only for lower frequencies.
> > Change the has_cdclk_squasher() helper to reflect this.
> >
> > bxt_get_cdclk() is not properly calculating HW clock for MTL, because
> > the squash formula is only prepared for DG2.
> > Apart from adding the cdclk table, align cdclk support with the new
> > cdclk_crawl_and_squash() introduced in previous patch.
> >
> > BSpec: 65243
> > Cc: Radhakrishna Sripada
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 95
> > +-
> > 1 file changed, 93 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index f7bc1013b149..6271eed0d7cf 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1222,7 +1222,7 @@ static void skl_cdclk_uninit_hw(struct
> > drm_i915_private *dev_priv)
> >
> > static bool has_cdclk_squasher(struct drm_i915_private *i915) {
> > - return IS_DG2(i915);
> > + return DISPLAY_VER(i915) >= 14 || IS_DG2(i915);
> > }
> >
> > struct intel_cdclk_vals {
> > @@ -1350,6 +1350,16 @@ static const struct intel_cdclk_vals
> dg2_cdclk_table[] = {
> > {}
> > };
> >
> > +static const struct intel_cdclk_vals mtl_cdclk_table[] = {
> > + { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 16, .waveform
> = 0xad5a },
> > + { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 16, .waveform
> = 0xb6b6 },
> > + { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16, .waveform
> = 0x },
> > + { .refclk = 38400, .cdclk = 48, .divider = 2, .ratio = 25, .waveform
> = 0x },
> > + { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29, .waveform
> = 0x },
> > + { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34, .waveform
> = 0x },
> > + {}
> > +};
> > +
> > static int bxt_calc_cdclk(struct drm_i915_private *dev_priv, int
> > min_cdclk) {
> > const struct intel_cdclk_vals *table =
> > dev_priv->display.cdclk.table; @@ -1479,6 +1489,76 @@ static void
> bxt_de_pll_readout(struct drm_i915_private *dev_priv,
> > cdclk_config->vco = ratio * cdclk_config->ref; }
> >
> > +static void mtl_get_cdclk(struct drm_i915_private *i915,
> > + struct intel_cdclk_config *cdclk_config) {
> > + const struct intel_cdclk_vals *table = i915->display.cdclk.table;
> > + u32 squash_ctl, divider, waveform;
> > + int div, i, ratio;
> > +
> > + bxt_de_pll_readout(i915, cdclk_config);
> > +
> > + cdclk_config->bypass = cdclk_config->ref / 2;
> > +
> > + if (cdclk_config->vco == 0) {
> > + cdclk_config->cdclk = cdclk_config->bypass;
> > + goto out;
> > + }
> > +
> > + divider = intel_de_read(i915, CDCLK_CTL) &
> BXT_CDCLK_CD2X_DIV_SEL_MASK;
> > + switch (divider) {
> > + case BXT_CDCLK_CD2X_DIV_SEL_1:
> > + div = 2;
> > + break;
> > + case BXT_CDCLK_CD2X_DIV_SEL_1_5:
> > + div = 3;
> > + break;
> > + case BXT_CDCLK_CD2X_DIV_SEL_2:
> > + div = 4;
> > + break;
> > + case BXT_CDCLK_CD2X_DIV_SEL_4:
> > + div = 8;
> > + break;
> > + default:
> > + MISSING_CASE(divider);
> > + return;
> > + }
> > +
> > + squash_ctl = intel_de_read(i915, CDCLK_SQUASH_CTL);
> > + if (squash_ctl & CDCLK_SQUASH_ENABLE)
> > + waveform = squash_ctl &
> CDCLK_SQUASH_WAVEFORM_MASK;
> > + else
> > + waveform = 0;
> > +
> > + ratio = cdclk_config->vco / cdclk_config->ref;
> > +
> > + for (i = 0, cdclk_config->cdclk = 0; table[i].refclk; i++) {
> > + if (table[i].refclk != cdclk_config->ref)
> > + continue;
> > +
> > + if (table[i].divider != div)
> > + continue;
> > +
> &
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
> -Original Message- > From: Ville Syrjälä > Sent: Monday, September 26, 2022 10:30 AM > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > ; Vivi, Rodrigo ; Navare, > Manasi D ; Roper, Matthew D > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Mon, Sep 26, 2022 at 05:21:40PM +, Srivatsa, Anusha wrote: > > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Friday, September 23, 2022 12:04 PM > > > To: Srivatsa, Anusha > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > ; Vivi, Rodrigo ; > > > Navare, Manasi D ; Roper, Matthew D > > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > On Fri, Sep 23, 2022 at 04:56:53PM +, Srivatsa, Anusha wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Ville Syrjälä > > > > > Sent: Tuesday, September 20, 2022 2:59 PM > > > > > To: Srivatsa, Anusha > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > > ; Vivi, Rodrigo > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote: > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Ville Syrjälä > > > > > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > > > > > To: Srivatsa, Anusha > > > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > > > > ; Vivi, Rodrigo > > > > > > > > > > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > > > > > This is a prep series for the actual cdclk refactoring > > > > > > > > that will be sent following this. Idea is to have a struct > > > > > > > > - cdclk_step that holds the following: > > > > > > > > - cdclk action (squash, crawl or modeset) > > > > > > > > - cdclk frequency > > > > > > > > which gets populated in atomic check. Driver uses the > > > > > > > > populated values during atomic commit to do the suitable > > > > > > > > sequence of actions like programming squash ctl registers > > > > > > > > in case of squashing or PLL sequence incase of modeset and so > on. > > > > > > > > > > > > > > > > This series just addresses the initial idea. The actual > > > > > > > > plumming in the atomic commit phase will be sent shortly. > > > > > > > > > > > > > > OK, people keep ignoring what I say so I just typed up the > > > > > > > code quickly. This to me seems like the most straightforward > > > > > > > way to do what > > > > > we need: > > > > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > > > > > > > > > Totally untested ofc, apart from me doing a quick scan > > > > > > > through our cdclk tables for the crawl+squahs platforms to > > > > > > > make sure that this approach should produce sane values. > > > > > > Ville, > > > > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config > > > > > > for this > > > > > purpose? > > > > > > > > > > You either > > > > > - start at old, crawl to mid, then squash to new > > > > > - start at old, squash to mid, then crawl to new > > > > > > > > Tested the changes on TGL(legacy) and DG2(squash). Took some time > > > > to > > > understand the code but the mid cdclk config logic works. @Ville > > > Syrjälä does replacing the intel_cdclk_can_squash() and > > > intel_cdclk_can_crawl() with your new cdclk_crawl_and_squash in atomic > check make sense? > > > > > > I don't think we should need any real logic at that point. > > > If we can squash and crawl then I think we can always do the cdclk > > > change w/o a modeset, at least with what we currently have defined > > > in the cdclk tables. > > > > @Ville Syrjälä is this patch in your radar to be sending out to the ML? Or > should I send it on your behalf? > > You can take over again if you want. Will do. Thanks Ville! Anusha > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
> -Original Message- > From: Ville Syrjälä > Sent: Friday, September 23, 2022 12:04 PM > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > ; Vivi, Rodrigo ; Navare, > Manasi D ; Roper, Matthew D > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Fri, Sep 23, 2022 at 04:56:53PM +, Srivatsa, Anusha wrote: > > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, September 20, 2022 2:59 PM > > > To: Srivatsa, Anusha > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > ; Vivi, Rodrigo > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Ville Syrjälä > > > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > > > To: Srivatsa, Anusha > > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > > ; Vivi, Rodrigo > > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > > > This is a prep series for the actual cdclk refactoring that > > > > > > will be sent following this. Idea is to have a struct - > > > > > > cdclk_step that holds the following: > > > > > > - cdclk action (squash, crawl or modeset) > > > > > > - cdclk frequency > > > > > > which gets populated in atomic check. Driver uses the > > > > > > populated values during atomic commit to do the suitable > > > > > > sequence of actions like programming squash ctl registers in > > > > > > case of squashing or PLL sequence incase of modeset and so on. > > > > > > > > > > > > This series just addresses the initial idea. The actual > > > > > > plumming in the atomic commit phase will be sent shortly. > > > > > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > > > quickly. This to me seems like the most straightforward way to > > > > > do what > > > we need: > > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > > > > > Totally untested ofc, apart from me doing a quick scan through > > > > > our cdclk tables for the crawl+squahs platforms to make sure > > > > > that this approach should produce sane values. > > > > Ville, > > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for > > > > this > > > purpose? > > > > > > You either > > > - start at old, crawl to mid, then squash to new > > > - start at old, squash to mid, then crawl to new > > > > Tested the changes on TGL(legacy) and DG2(squash). Took some time to > understand the code but the mid cdclk config logic works. @Ville Syrjälä does > replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your > new cdclk_crawl_and_squash in atomic check make sense? > > I don't think we should need any real logic at that point. > If we can squash and crawl then I think we can always do the cdclk change > w/o a modeset, at least with what we currently have defined in the cdclk > tables. @Ville Syrjälä is this patch in your radar to be sending out to the ML? Or should I send it on your behalf? Anusha > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
> -Original Message- > From: Ville Syrjälä > Sent: Tuesday, September 20, 2022 2:59 PM > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > ; Vivi, Rodrigo > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote: > > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > To: Srivatsa, Anusha > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > ; Vivi, Rodrigo > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > This is a prep series for the actual cdclk refactoring that will > > > > be sent following this. Idea is to have a struct - cdclk_step that > > > > holds the following: > > > > - cdclk action (squash, crawl or modeset) > > > > - cdclk frequency > > > > which gets populated in atomic check. Driver uses the populated > > > > values during atomic commit to do the suitable sequence of actions > > > > like programming squash ctl registers in case of squashing or PLL > > > > sequence incase of modeset and so on. > > > > > > > > This series just addresses the initial idea. The actual plumming > > > > in the atomic commit phase will be sent shortly. > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > quickly. This to me seems like the most straightforward way to do what > we need: > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > Totally untested ofc, apart from me doing a quick scan through our > > > cdclk tables for the crawl+squahs platforms to make sure that this > > > approach should produce sane values. > > Ville, > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this > purpose? > > You either > - start at old, crawl to mid, then squash to new > - start at old, squash to mid, then crawl to new Tested the changes on TGL(legacy) and DG2(squash). Took some time to understand the code but the mid cdclk config logic works. @Ville Syrjälä does replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your new cdclk_crawl_and_squash in atomic check make sense? Anusha > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
> -Original Message- > From: Ville Syrjälä > Sent: Tuesday, September 20, 2022 1:20 AM > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > ; Vivi, Rodrigo > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > This is a prep series for the actual cdclk refactoring that will be > > sent following this. Idea is to have a struct - cdclk_step that holds > > the following: > > - cdclk action (squash, crawl or modeset) > > - cdclk frequency > > which gets populated in atomic check. Driver uses the populated values > > during atomic commit to do the suitable sequence of actions like > > programming squash ctl registers in case of squashing or PLL sequence > > incase of modeset and so on. > > > > This series just addresses the initial idea. The actual plumming in > > the atomic commit phase will be sent shortly. > > OK, people keep ignoring what I say so I just typed up the code quickly. This > to me seems like the most straightforward way to do what we need: > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > Totally untested ofc, apart from me doing a quick scan through our cdclk > tables for the crawl+squahs platforms to make sure that this approach > should produce sane values. Ville, Why have a mid cdclk_config? Cant we use the new-cdclk-config for this purpose? Anusha > > > > Cc: Ville Syrjälä > > Cc: Uma Shankar > > Cc: Rodrigo Vivi > > > > Anusha Srivatsa (6): > > drm/i915/display Add dg2_prog_squash_ctl() helper > > drm/i915/display: add cdclk action struct to cdclk_config > > drm/i915/display: Embed the new struct steps for squashing > > drm/i915/display: Embed the new struct steps for crawling > > drm/i915/display: Embed the new struct steps for modeset > > drm/i915/display: Dump the new cdclk config values > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 77 > > +- drivers/gpu/drm/i915/display/intel_cdclk.h | > > 16 - > > 2 files changed, 74 insertions(+), 19 deletions(-) > > > > -- > > 2.25.1 > > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH 6/6] drm/i915/display: Dump the new cdclk config values
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, September 20, 2022 12:27 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 6/6] drm/i915/display: Dump the new cdclk
> config values
>
> On Fri, 16 Sep 2022, Anusha Srivatsa wrote:
> > Add a helper function to get stringify values of the desired cdclk
> > action and dump it with rest of the cdclk config values
> >
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 18 --
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index bc627daade3e..12f5e4d23245 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1688,6 +1688,19 @@ static u32 cdclk_squash_waveform(struct
> > drm_i915_private *dev_priv,
> >
> > return 0x;
> > }
> > +static const char *cdclk_sequence_to_string(enum cdclk_sequence
> > +cdclk_sequence)
>
> For any enum foobar, this would be customarily called foobar_name(), i.e.
> cdclk_sequence_name(). (Though the enum should probably be renamed as
> mentioned earlier.)
Will do. The initial change and then change here.
> > +{
> > + switch (cdclk_sequence) {
> > + case CDCLK_SQUASH_ONLY:
> > + return "Squash only";
> > + case CDCLK_CRAWL_ONLY:
> > + return "Crawl only";
> > + case CDCLK_LEGACY:
> > + return "Legacy method";
> > + default:
> > + return "Not a valid cdclk sequence";
> > + }
> > +}
> >
> > static void dg2_prog_squash_ctl(struct drm_i915_private *i915, u16
> > waveform) { @@ -2083,10 +2096,11 @@ void
> > intel_cdclk_dump_config(struct drm_i915_private *i915,
> > const struct intel_cdclk_config *cdclk_config,
> > const char *context)
> > {
> > - drm_dbg_kms(>drm, "%s %d kHz, VCO %d kHz, ref %d kHz,
> bypass %d kHz, voltage level %d\n",
> > + drm_dbg_kms(>drm, "%s %d kHz, VCO %d kHz, ref %d kHz,
> bypass
> > +%d kHz, voltage level %d, %s action\n",
>
> "%s action" leads to:
>
> Squash only action
> Crawl only action
> Legacy method action
> Not a valid cdclk sequence action
>
> A bit odd perhaps. *shrug*
Yeah now I see it.
Will thin over what can be a better replacement.
Anusha
> BR,
> Jani.
>
> > context, cdclk_config->cdclk, cdclk_config->vco,
> > cdclk_config->ref, cdclk_config->bypass,
> > - cdclk_config->voltage_level);
> > + cdclk_config->voltage_level,
> > + cdclk_sequence_to_string(cdclk_config->steps->action));
> > }
> >
> > /**
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 3/6] drm/i915/display: Embed the new struct steps for squashing
> -Original Message-
> From: Navare, Manasi D
> Sent: Monday, September 19, 2022 12:39 PM
> To: Jani Nikula
> Cc: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 3/6] drm/i915/display: Embed the new struct
> steps for squashing
>
> On Mon, Sep 19, 2022 at 12:27:55PM +0300, Jani Nikula wrote:
> > On Fri, 16 Sep 2022, Anusha Srivatsa wrote:
> > > Populate the new struct steps for squash case.
> > >
> > > Signed-off-by: Anusha Srivatsa
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 220d32adbd12..d2e81134b6f2 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -1973,8 +1973,9 @@ static bool intel_cdclk_can_crawl(struct
> > > drm_i915_private *dev_priv,
> > >
> > > static bool intel_cdclk_can_squash(struct drm_i915_private *dev_priv,
> > > const struct intel_cdclk_config *a,
> > > -const struct intel_cdclk_config *b)
> > > +struct intel_cdclk_config *b)
> >
> > Why are you dropping const?
@Jani Nikula @Navare, Manasi D
Looking at intel_modeset_calc_cdclk() from where this function is called,
new_cdclk_state is not a const. Since we are going to be populating it in
intel_cdclk_can_squash() and in intel_cdclk_can_crawl() in the next patch,
keeping it non-const made sense.
> >
> > > {
> > > + struct cdclk_step *cdclk_transition = b->steps;
> >
> > The type name has step, the array is named steps, why is the variable
> > "transition"?
>
> Yes I agree that the name cdclk_tranistion is confusing rather having
> cdclk_transition is unnecessary.
> Why cant you directly access b->steps->action, b->steps->cdclk
>
Now that I look at it again, I see that cdclk_transition might be confusing. I
will either rename it or directly access it as Manasi suggested.
Anusha
> Manasi
>
> >
> > > /*
> > >* FIXME should store a bit more state in intel_cdclk_config
> > >* to differentiate squasher vs. cd2x divider properly. For @@
> > > -1984,6 +1985,12 @@ static bool intel_cdclk_can_squash(struct
> drm_i915_private *dev_priv,
> > > if (!has_cdclk_squasher(dev_priv))
> > > return false;
> > >
> > > + if (a->cdclk != b->cdclk && a->vco != 0 &&
> > > + a->vco == b->vco && a->ref == b->ref) {
> > > + cdclk_transition->action = CDCLK_SQUASH_ONLY;
> > > + cdclk_transition->cdclk = b->cdclk;
> > > + }
> > > +
> > > return a->cdclk != b->cdclk &&
> > > a->vco != 0 &&
> > > a->vco == b->vco &&
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/6] drm/i915/display: add cdclk action struct to cdclk_config
> -Original Message-
> From: Navare, Manasi D
> Sent: Monday, September 19, 2022 12:33 PM
> To: Jani Nikula
> Cc: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/6] drm/i915/display: add cdclk action struct
> to cdclk_config
>
> On Mon, Sep 19, 2022 at 12:26:19PM +0300, Jani Nikula wrote:
> > On Fri, 16 Sep 2022, Anusha Srivatsa wrote:
> > > The struct has the action to be performed - squash, crawl or modeset
> > > and the corresponding cdclk which is the desired cdclk. This is the
> > > structure that gets populated during atomic check once it is
> > > determined what the cdclk change looks like
> > >
> > > Signed-off-by: Anusha Srivatsa
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.h | 14 ++
> > > 1 file changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.h
> > > index c674879a84a5..3869f93e8ad2 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> > > @@ -11,13 +11,27 @@
> > > #include "intel_display.h"
> > > #include "intel_global_state.h"
> > >
> > > +#define MAX_CDCLK_ACTIONS 1
> >
> > Okay, this review is just nitpicks, but they'll need to get fixed
> > eventually so here goes.
> >
> > No tab after #define.
> >
> > > +
> > > struct drm_i915_private;
> > > struct intel_atomic_state;
> > > struct intel_crtc_state;
> > >
> > > +enum cdclk_sequence {
> >
> > Needs to be named intel_ something.
>
> Agree here
Agree with all the above. Will make the suitable changes.
> >
> > > + CDCLK_INVALID_ACTION = -1,
> > > +
> > > + CDCLK_SQUASH_ONLY = 0,
> > > + CDCLK_CRAWL_ONLY,
> > > + CDCLK_LEGACY,
> > > +};
> > > +
> > > struct intel_cdclk_config {
> > > unsigned int cdclk, vco, ref, bypass;
> > > u8 voltage_level;
> > > + struct cdclk_step {
> >
> > Needs to be named intel_ something.
> >
> > Since this is used independently, I'd prefer it to be defined outside
> > of struct intel_cdclk_config.
>
> I think the point of having it as part of intel_cdclk_config is that because
> we
> already pass cdclk_config to set_cdclk where these actions are going to get
> used.
Yes. That is correct. This eventually gets used in bxt_set_cdclk() and we are
already passing cdclk_config there. Having this new struct embedded in
cdclk_config makes the fields - action and cdclk to be accessible without
having to change the function signature of set_cdclk()
Anusha
> Manasi
>
> >
> > > + enum cdclk_sequence action;
> > > + u32 cdclk;
> > > + } steps[MAX_CDCLK_ACTIONS];
> > > };
> > >
> > > struct intel_cdclk_state {
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/4] drm/i915/display: Add CDCLK actions to intel_cdclk_state
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, September 14, 2022 2:43 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915/display: Add CDCLK actions to
> intel_cdclk_state
>
> On Thu, Sep 15, 2022 at 12:22:53AM +0300, Ville Syrjälä wrote:
> > On Fri, Aug 19, 2022 at 05:58:19PM -0700, Anusha Srivatsa wrote:
> > > This is a prep patch for what the rest of the series does.
> > >
> > > Add existing actions that change cdclk - squash, crawl, modeset to
> > > intel_cdclk_state so we have access to the cdclk values that are in
> > > transition.
> > >
> > > Cc: Jani Nikula
> > > Signed-off-by: Anusha Srivatsa
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.h | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.h
> > > index b535cf6a7d9e..43835688ee02 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> > > @@ -15,6 +15,14 @@ struct drm_i915_private; struct
> > > intel_atomic_state; struct intel_crtc_state;
> > >
> > > +enum cdclk_actions {
> > > + INTEL_CDCLK_MODESET = 0,
> > > + INTEL_CDCLK_SQUASH,
> > > + INTEL_CDCLK_CRAWL,
> > > + INTEL_CDCLK_NOOP,
> > > + MAX_CDCLK_ACTIONS
> > > +};
> >
> > This whole actions thing feels overly complicated to me.
> > I think we should only need something like this:
> >
> > if (new.squash > old.squash) {
> > mid.vco = old.vco;
> > mid.squash = new.squash;
> > } else {
> > mid.vco = new.vco;
> > mid.squash = old.squash;
> > }
> > /*
> > * bunch of asserts here to make sure
> > * the mid state looks sane.
> > */
> > set_cdclk(mid);
> > set_cdclk(new);
> >
> > And perhaps the current set_cdclk needs to get chunked up into smaller
> > pieces so we don't do all the pre/post stuff more than once
> > needlessly.
>
> One idea might be to pass just a pair of flags to set_cdclk() whether to skip
> the pre/post steps.
This is all considering that the new struct cdclk_step is embedded in
cdclk_config and not cdclk_state. I am not understanding why cdclk-state is not
accessible from bxt_set_cdclk.
What if I add cdclk_state to the dev_priv? bxt_set_cdclk() anyway has dev_priv.
Anusha
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH 21/23] drm/i915/dmc: MTL DMC debugfs entries
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, August 2, 2022 11:23 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 21/23] drm/i915/dmc: MTL DMC debugfs
> entries
>
> On Wed, Jul 27, 2022 at 06:34:18PM -0700, Radhakrishna Sripada wrote:
> > From: Anusha Srivatsa
> >
> > MTL needs both Pipe A and Pipe B DMC to be loaded along with Main DMC.
> > Patch also adds
>
> That's true, but it's unrelated to this patch. intel_dmc_load_program()
> always loads all of the pipe firmwares (including pipe C and pipe D) assuming
> it found them in the firmware file.
>
> > DMC debug register for MTL.
> >
> > BSpec: 49788
> > Cc: Matt Roper
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> > b/drivers/gpu/drm/i915/display/intel_dmc.c
> > index 9c4f442fa407..2fabb2760474 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > @@ -1005,7 +1005,7 @@ static int intel_dmc_debugfs_status_show(struct
> seq_file *m, void *unused)
> > seq_printf(m, "Pipe A fw loaded: %s\n",
> >str_yes_no(dmc->dmc_info[DMC_FW_PIPEA].payload));
> > seq_printf(m, "Pipe B fw support: %s\n",
> > - str_yes_no(IS_ALDERLAKE_P(i915)));
> > + str_yes_no(DISPLAY_VER(i915) >= 13));
>
> What is this debugfs trying to tell us? Pipe DMC fw for all four pipes has
> been supported since TGL. So the output here is misleading (and incomplete
> since it doesn't include C/D).
>
> The thing that changed in DG2 was that we were required to upload the pipe
> A firmware along with the main firmware (other pipes optional).
> The thing that further changed in ADL-P was that we were required to upload
> *both* pipe A and pipe B along with the main firmware (other two pipes still
> optional).
>
> Even if the output here was trying to indicate which pipe firmware(s) need to
> be uploaded at the same time as the main firmware (rather than being
> uploaded later), the change here wouldn't be correct since as noted above,
> DG2 (which has display version 13) only required pipe A and not B.
>
> I think we probably need to decide what the purpose of this debugfs is
> supposed to be and then rework it accordingly.
>
IMO the debugfs should give a gist of the different firmwares that was loaded
and which ones the platform actually needs. At this point the driver loads all
available firmwares even if the platform doesn't need them. Debugfs should
clearly state wat Is needed and if that is loaded or not.
Something like:
Pipe A loaded: yes/no
Pipe B loaded: yes/no
And so on.
As well as:
Pipe A needed: yes/no
Pipe B needed: yes/no
Does this sound like the right way forward?
Anusha
> Matt
>
> > seq_printf(m, "Pipe B fw loaded: %s\n",
> >str_yes_no(dmc->dmc_info[DMC_FW_PIPEB].payload));
> >
> > @@ -1029,9 +1029,9 @@ static int intel_dmc_debugfs_status_show(struct
> seq_file *m, void *unused)
> > * reg for DC3CO debugging and validation,
> > * but TGL DMC f/w is using DMC_DEBUG3 reg for DC3CO
> counter.
> > */
> > - seq_printf(m, "DC3CO count: %d\n",
> > - intel_de_read(i915, IS_DGFX(i915) ?
> > -DG1_DMC_DEBUG3 :
> TGL_DMC_DEBUG3));
> > + seq_printf(m, "DC3CO count: %d\n", intel_de_read(i915,
> > + (IS_DGFX(i915) || DISPLAY_VER(i915) >= 14) ?
> > + DG1_DMC_DEBUG3 : TGL_DMC_DEBUG3));
> > } else {
> > dc5_reg = IS_BROXTON(i915) ? BXT_DMC_DC3_DC5_COUNT :
> > SKL_DMC_DC3_DC5_COUNT;
> > --
> > 2.25.1
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
Re: [Intel-gfx] [PATCH 06/23] drm/i915/mtl: Add PCH support
> -Original Message-
> From: Sripada, Radhakrishna
> Sent: Wednesday, July 27, 2022 6:34 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha
> Subject: [PATCH 06/23] drm/i915/mtl: Add PCH support
>
> Add support for Meteorpoint(MTP) PCH used with Meteorlake.
>
> Cc: Matt Roper
> Cc: Anusha Srivatsa
> Signed-off-by: Clint Taylor
> Signed-off-by: Radhakrishna Sripada
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_pch.c | 9 -
> drivers/gpu/drm/i915/intel_pch.h | 4
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pch.c
> b/drivers/gpu/drm/i915/intel_pch.c
> index 0fec25be146a..ba9843cb1b13 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -138,6 +138,11 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id)
> drm_WARN_ON(_priv->drm,
> !IS_ALDERLAKE_S(dev_priv) &&
> !IS_ALDERLAKE_P(dev_priv));
> return PCH_ADP;
> + case INTEL_PCH_MTP_DEVICE_ID_TYPE:
> + case INTEL_PCH_MTP2_DEVICE_ID_TYPE:
> + drm_dbg_kms(_priv->drm, "Found Meteor Lake
> PCH\n");
> + drm_WARN_ON(_priv->drm,
> !IS_METEORLAKE(dev_priv));
> + return PCH_MTP;
> default:
> return PCH_NONE;
> }
> @@ -166,7 +171,9 @@ intel_virt_detect_pch(const struct drm_i915_private
> *dev_priv,
>* make an educated guess as to which PCH is really there.
>*/
>
> - if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv))
> + if (IS_METEORLAKE(dev_priv))
> + id = INTEL_PCH_MTP_DEVICE_ID_TYPE;
> + else if (IS_ALDERLAKE_S(dev_priv) || IS_ALDERLAKE_P(dev_priv))
> id = INTEL_PCH_ADP_DEVICE_ID_TYPE;
> else if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv))
> id = INTEL_PCH_TGP_DEVICE_ID_TYPE;
> diff --git a/drivers/gpu/drm/i915/intel_pch.h
> b/drivers/gpu/drm/i915/intel_pch.h
> index 7c8ce9781d1a..32aff5a70d04 100644
> --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -25,6 +25,7 @@ enum intel_pch {
> PCH_ICP,/* Ice Lake/Jasper Lake PCH */
> PCH_TGP,/* Tiger Lake/Mule Creek Canyon PCH */
> PCH_ADP,/* Alder Lake PCH */
> + PCH_MTP,/* Meteor Lake PCH */
>
> /* Fake PCHs, functionality handled on the same PCI dev */
> PCH_DG1 = 1024,
> @@ -57,12 +58,15 @@ enum intel_pch {
> #define INTEL_PCH_ADP2_DEVICE_ID_TYPE0x5180
> #define INTEL_PCH_ADP3_DEVICE_ID_TYPE0x7A00
> #define INTEL_PCH_ADP4_DEVICE_ID_TYPE0x5480
> +#define INTEL_PCH_MTP_DEVICE_ID_TYPE 0x7E00
> +#define INTEL_PCH_MTP2_DEVICE_ID_TYPE0xAE00
> #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
> #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
> #define INTEL_PCH_QEMU_DEVICE_ID_TYPE0x2900 /* qemu q35
> has 2918 */
>
> #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
> #define INTEL_PCH_ID(dev_priv) ((dev_priv)->pch_id)
> +#define HAS_PCH_MTP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_MTP)
> #define HAS_PCH_DG2(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_DG2)
> #define HAS_PCH_ADP(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_ADP)
> #define HAS_PCH_DG1(dev_priv)
> (INTEL_PCH_TYPE(dev_priv) == PCH_DG1)
> --
> 2.25.1
Re: [Intel-gfx] [PATCH] drm/i915: Pass drm_i915_private struct instead of gt for gen11_gu_misc_irq_handler/ack()
Thanks Tvrtko :)
@Roper, Matthew D Did you have any other feedback on this patch?
Anusha
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Tuesday, July 26, 2022 1:59 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org; Ursulin, Tvrtko
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Pass drm_i915_private struct
> instead of gt for gen11_gu_misc_irq_handler/ack()
>
>
> On 25/07/2022 19:38, Srivatsa, Anusha wrote:
> > @Ursulin, Tvrtko Is this wat you had in mind?
>
> Two functions aligned in prototype yes - but I left to you guys which
> prototype is correct. AFAICT Matt looked and concluded i915 is correct so
> that's good for me.
>
> Regards,
>
> Tvrtko
>
> >> -Original Message-
> >> From: Srivatsa, Anusha
> >> Sent: Thursday, July 21, 2022 3:51 PM
> >> To: intel-gfx@lists.freedesktop.org
> >> Cc: Srivatsa, Anusha ; Ursulin, Tvrtko
> >> ; Roper, Matthew D
> >>
> >> Subject: [PATCH] drm/i915: Pass drm_i915_private struct instead of gt
> >> for
> >> gen11_gu_misc_irq_handler/ack()
> >>
> >> gen11_gu_misc_irq_handler() and gen11_gu_misc_ack() do nothing tile
> >> specific.
> >>
> >> v2: gen11_gu_misc_irq_ack() tile agnostic like
> >> gen11_gu_misc_irq_handler()
> >> (Tvrtko)
> >>
> >> Cc: Tvrtko Ursulin
> >> Cc: Matt Roper
> >> Signed-off-by: Anusha Srivatsa
> >> ---
> >> drivers/gpu/drm/i915/i915_irq.c | 16
> >> 1 file changed, 8 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c index 73cebc6aa650..eb37b6bacaac
> >> 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -2653,9 +2653,9 @@ static irqreturn_t gen8_irq_handler(int irq,
> >> void
> >> *arg) }
> >>
> >> static u32
> >> -gen11_gu_misc_irq_ack(struct intel_gt *gt, const u32 master_ctl)
> >> +gen11_gu_misc_irq_ack(struct drm_i915_private *i915, const u32
> >> +master_ctl)
> >> {
> >> - void __iomem * const regs = gt->uncore->regs;
> >> + void __iomem * const regs = i915->uncore.regs;
> >>u32 iir;
> >>
> >>if (!(master_ctl & GEN11_GU_MISC_IRQ)) @@ -2669,10 +2669,10
> @@
> >> gen11_gu_misc_irq_ack(struct intel_gt *gt, const u32 master_ctl) }
> >>
> >> static void
> >> -gen11_gu_misc_irq_handler(struct intel_gt *gt, const u32 iir)
> >> +gen11_gu_misc_irq_handler(struct drm_i915_private *i915, const u32
> >> +iir)
> >> {
> >>if (iir & GEN11_GU_MISC_GSE)
> >> - intel_opregion_asle_intr(gt->i915);
> >> + intel_opregion_asle_intr(i915);
> >> }
> >>
> >> static inline u32 gen11_master_intr_disable(void __iomem * const
> >> regs) @@
> >> -2736,11 +2736,11 @@ static irqreturn_t gen11_irq_handler(int irq,
> >> void
> >> *arg)
> >>if (master_ctl & GEN11_DISPLAY_IRQ)
> >>gen11_display_irq_handler(i915);
> >>
> >> - gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
> >> + gu_misc_iir = gen11_gu_misc_irq_ack(i915, master_ctl);
> >>
> >>gen11_master_intr_enable(regs);
> >>
> >> - gen11_gu_misc_irq_handler(gt, gu_misc_iir);
> >> + gen11_gu_misc_irq_handler(i915, gu_misc_iir);
> >>
> >>pmu_irq_stats(i915, IRQ_HANDLED);
> >>
> >> @@ -2801,11 +2801,11 @@ static irqreturn_t dg1_irq_handler(int irq,
> >> void
> >> *arg)
> >>if (master_ctl & GEN11_DISPLAY_IRQ)
> >>gen11_display_irq_handler(i915);
> >>
> >> - gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
> >> + gu_misc_iir = gen11_gu_misc_irq_ack(i915, master_ctl);
> >>
> >>dg1_master_intr_enable(regs);
> >>
> >> - gen11_gu_misc_irq_handler(gt, gu_misc_iir);
> >> + gen11_gu_misc_irq_handler(i915, gu_misc_iir);
> >>
> >>pmu_irq_stats(i915, IRQ_HANDLED);
> >>
> >> --
> >> 2.25.1
> >
Re: [Intel-gfx] [PATCH] drm/i915: Pass drm_i915_private struct instead of gt for gen11_gu_misc_irq_handler/ack()
@Ursulin, Tvrtko Is this wat you had in mind?
Anusha
> -Original Message-
> From: Srivatsa, Anusha
> Sent: Thursday, July 21, 2022 3:51 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Ursulin, Tvrtko
> ; Roper, Matthew D
>
> Subject: [PATCH] drm/i915: Pass drm_i915_private struct instead of gt for
> gen11_gu_misc_irq_handler/ack()
>
> gen11_gu_misc_irq_handler() and gen11_gu_misc_ack() do nothing tile
> specific.
>
> v2: gen11_gu_misc_irq_ack() tile agnostic like gen11_gu_misc_irq_handler()
> (Tvrtko)
>
> Cc: Tvrtko Ursulin
> Cc: Matt Roper
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_irq.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c index 73cebc6aa650..eb37b6bacaac
> 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2653,9 +2653,9 @@ static irqreturn_t gen8_irq_handler(int irq, void
> *arg) }
>
> static u32
> -gen11_gu_misc_irq_ack(struct intel_gt *gt, const u32 master_ctl)
> +gen11_gu_misc_irq_ack(struct drm_i915_private *i915, const u32
> +master_ctl)
> {
> - void __iomem * const regs = gt->uncore->regs;
> + void __iomem * const regs = i915->uncore.regs;
> u32 iir;
>
> if (!(master_ctl & GEN11_GU_MISC_IRQ)) @@ -2669,10 +2669,10
> @@ gen11_gu_misc_irq_ack(struct intel_gt *gt, const u32 master_ctl) }
>
> static void
> -gen11_gu_misc_irq_handler(struct intel_gt *gt, const u32 iir)
> +gen11_gu_misc_irq_handler(struct drm_i915_private *i915, const u32 iir)
> {
> if (iir & GEN11_GU_MISC_GSE)
> - intel_opregion_asle_intr(gt->i915);
> + intel_opregion_asle_intr(i915);
> }
>
> static inline u32 gen11_master_intr_disable(void __iomem * const regs) @@
> -2736,11 +2736,11 @@ static irqreturn_t gen11_irq_handler(int irq, void
> *arg)
> if (master_ctl & GEN11_DISPLAY_IRQ)
> gen11_display_irq_handler(i915);
>
> - gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
> + gu_misc_iir = gen11_gu_misc_irq_ack(i915, master_ctl);
>
> gen11_master_intr_enable(regs);
>
> - gen11_gu_misc_irq_handler(gt, gu_misc_iir);
> + gen11_gu_misc_irq_handler(i915, gu_misc_iir);
>
> pmu_irq_stats(i915, IRQ_HANDLED);
>
> @@ -2801,11 +2801,11 @@ static irqreturn_t dg1_irq_handler(int irq, void
> *arg)
> if (master_ctl & GEN11_DISPLAY_IRQ)
> gen11_display_irq_handler(i915);
>
> - gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
> + gu_misc_iir = gen11_gu_misc_irq_ack(i915, master_ctl);
>
> dg1_master_intr_enable(regs);
>
> - gen11_gu_misc_irq_handler(gt, gu_misc_iir);
> + gen11_gu_misc_irq_handler(i915, gu_misc_iir);
>
> pmu_irq_stats(i915, IRQ_HANDLED);
>
> --
> 2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/display: Cleanup intel_phy_is_combo()
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, July 21, 2022 1:50 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Murthy, Arun R
>
> Subject: Re: [PATCH] drm/i915/display: Cleanup intel_phy_is_combo()
>
> On Thu, Jul 21, 2022 at 01:17:54PM -0700, Anusha Srivatsa wrote:
> > No functional change. Cleanup the intel_phy_is_combo
>
> But there actually is a functional change here --- display version 14 will now
> (properly) fall through to the 'else' branch instead of being picked up by the
> 11/12/adl branch. I believe that was your original motivation for this patch,
> so you may want to mention that in the commit message (and drop the "no
> functional change" statement).
>
> The code change itself looks fine to me since it seems like the traditional
> combo PHYs may be a thing of the past and we don't want to keep assuming
> future platforms will have any.
>
With the change in commit message can I add your reviewed-by laong with Arun's?
Anusha
> Matt
>
> > to accommodate for cases where combo phy is not available.
> >
> > v2: retain comment that explains DG2 returning false from
> > intel_phy_is_combo() (Arun)
> >
> > Cc: Arun R Murthy
> > Cc: Matt Roper
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 14 ++
> > 1 file changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a0f84cbe974f..b9d0be7753a8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2082,22 +2082,20 @@ bool intel_phy_is_combo(struct
> > drm_i915_private *dev_priv, enum phy phy) {
> > if (phy == PHY_NONE)
> > return false;
> > - else if (IS_DG2(dev_priv))
> > - /*
> > -* DG2 outputs labelled as "combo PHY" in the bspec use
> > -* SNPS PHYs with completely different programming,
> > -* hence we always return false here.
> > -*/
> > - return false;
> > else if (IS_ALDERLAKE_S(dev_priv))
> > return phy <= PHY_E;
> > else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
> > return phy <= PHY_D;
> > else if (IS_JSL_EHL(dev_priv))
> > return phy <= PHY_C;
> > - else if (DISPLAY_VER(dev_priv) >= 11)
> > + else if (IS_ALDERLAKE_P(dev_priv) || IS_DISPLAY_VER(dev_priv, 11,
> > +12))
> > return phy <= PHY_B;
> > else
> > + /*
> > +* DG2 outputs labelled as "combo PHY" in the bspec use
> > +* SNPS PHYs with completely different programming,
> > +* hence we always return false here.
> > +*/
> > return false;
> > }
> >
> > --
> > 2.25.1
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
Re: [Intel-gfx] [PATCH] drm/i915: Pass drm_i915_private struct instead of gt for gen11_gu_misc_irq_handler()
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Wednesday, July 20, 2022 2:38 AM
> To: Roper, Matthew D ; Srivatsa, Anusha
>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Pass drm_i915_private struct
> instead of gt for gen11_gu_misc_irq_handler()
>
>
> On 18/07/2022 19:54, Matt Roper wrote:
> > On Mon, Jul 18, 2022 at 11:34:24AM -0700, Anusha Srivatsa wrote:
> >> gen11_gu_misc_irq_handler() does not do anything tile specific.
> >>
> >> Cc: Matt Roper
> >> Signed-off-by: Anusha Srivatsa
> >
> > Reviewed-by: Matt Roper
> >
> >> ---
> >> drivers/gpu/drm/i915/i915_irq.c | 8
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c index 73cebc6aa650..c304af777d58
> >> 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -2669,10 +2669,10 @@ gen11_gu_misc_irq_ack(struct intel_gt *gt,
> const u32 master_ctl)
> >> }
> >>
> >> static void
> >> -gen11_gu_misc_irq_handler(struct intel_gt *gt, const u32 iir)
> >> +gen11_gu_misc_irq_handler(struct drm_i915_private *i915, const u32
> >> +iir)
> >> {
> >>if (iir & GEN11_GU_MISC_GSE)
> >> - intel_opregion_asle_intr(gt->i915);
> >> + intel_opregion_asle_intr(i915);
> >> }
> >>
> >> static inline u32 gen11_master_intr_disable(void __iomem * const
> >> regs) @@ -2740,7 +2740,7 @@ static irqreturn_t gen11_irq_handler(int
> >> irq, void *arg)
> >>
>
> Maybe this is correct but it leaves this, round about here:
>
> gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
>
> So _if_ these registers are truly not per GT, or don't live in the GT block,
> change this one as well?
Tvrtko,
gen11_gu_misc_irq_ack() does not fall in the same category. We do operations
where we grab register per gt and do some writes that are not gt agnostic.
Anusha
> Regards,
>
> Tvrtko
>
> >>gen11_master_intr_enable(regs);
> >>
> >> - gen11_gu_misc_irq_handler(gt, gu_misc_iir);
> >> + gen11_gu_misc_irq_handler(i915, gu_misc_iir);
> >>
> >>pmu_irq_stats(i915, IRQ_HANDLED);
> >>
> >> @@ -2805,7 +2805,7 @@ static irqreturn_t dg1_irq_handler(int irq,
> >> void *arg)
> >>
> >>dg1_master_intr_enable(regs);
> >>
> >> - gen11_gu_misc_irq_handler(gt, gu_misc_iir);
> >> + gen11_gu_misc_irq_handler(i915, gu_misc_iir);
> >>
> >>pmu_irq_stats(i915, IRQ_HANDLED);
> >>
> >> --
> >> 2.25.1
> >>
> >
Re: [Intel-gfx] [PATCH] drm/i915/display: Cleanup intel_phy_is_combo()
> -Original Message-
> From: Murthy, Arun R
> Sent: Tuesday, July 19, 2022 7:34 PM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Cleanup
> intel_phy_is_combo()
>
> > > -Original Message-
> > > From: Murthy, Arun R
> > > Sent: Monday, July 18, 2022 8:32 PM
> > > To: Srivatsa, Anusha ; intel-
> > > g...@lists.freedesktop.org
> > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Cleanup
> > > intel_phy_is_combo()
> > >
> > > > -Original Message-
> > > > From: Intel-gfx On
> > > > Behalf Of Anusha Srivatsa
> > > > Sent: Tuesday, July 19, 2022 12:42 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Subject: [Intel-gfx] [PATCH] drm/i915/display: Cleanup
> > > > intel_phy_is_combo()
> > > >
> > > > No functional change. Cleanup the intel_phy_is_combo to accomodate
> > > > for cases where combo phy is not available.
> > > >
> > > > Cc: Matt Roper
> > > > Signed-off-by: Anusha Srivatsa
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 9 +
> > > > 1 file changed, 1 insertion(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index a0f84cbe974f..b69208cf9a5e 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -2082,20 +2082,13 @@ bool intel_phy_is_combo(struct
> > > > drm_i915_private *dev_priv, enum phy phy) {
> > > > if (phy == PHY_NONE)
> > > > return false;
> > > > - else if (IS_DG2(dev_priv))
> > > > - /*
> > > > -* DG2 outputs labelled as "combo PHY" in the bspec use
> > > > -* SNPS PHYs with completely different programming,
> > > > -* hence we always return false here.
> > > > -*/
> > > > - return false;
> > > I feel it would be good to retain this. This is very well commented.
> > > In future upon adding something like DISPLAY_VER(dev_priv) >= 11,
> > > like the one done below can create confusion.
> >
> > What if I retain the comments with the code change?
> >
> Retaining this comment will do, but I feel this cleanup can be taken upon
> updating this with the future platforms. Other can comment over here.
We need this for MTL. Hence the cleanup :)
Anusha
> Thanks and Regards,
> Arun R Murthy
>
Re: [Intel-gfx] [PATCH] drm/i915/display: Cleanup intel_phy_is_combo()
> -Original Message-
> From: Murthy, Arun R
> Sent: Monday, July 18, 2022 8:32 PM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Cleanup
> intel_phy_is_combo()
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Anusha Srivatsa
> > Sent: Tuesday, July 19, 2022 12:42 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH] drm/i915/display: Cleanup
> > intel_phy_is_combo()
> >
> > No functional change. Cleanup the intel_phy_is_combo to accomodate for
> > cases where combo phy is not available.
> >
> > Cc: Matt Roper
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 9 +
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a0f84cbe974f..b69208cf9a5e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2082,20 +2082,13 @@ bool intel_phy_is_combo(struct
> > drm_i915_private *dev_priv, enum phy phy) {
> > if (phy == PHY_NONE)
> > return false;
> > - else if (IS_DG2(dev_priv))
> > - /*
> > -* DG2 outputs labelled as "combo PHY" in the bspec use
> > -* SNPS PHYs with completely different programming,
> > -* hence we always return false here.
> > -*/
> > - return false;
> I feel it would be good to retain this. This is very well commented. In future
> upon adding something like DISPLAY_VER(dev_priv) >= 11, like the one done
> below can create confusion.
What if I retain the comments with the code change?
Anusha
>
> > else if (IS_ALDERLAKE_S(dev_priv))
> > return phy <= PHY_E;
> > else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
> > return phy <= PHY_D;
> > else if (IS_JSL_EHL(dev_priv))
> > return phy <= PHY_C;
> > - else if (DISPLAY_VER(dev_priv) >= 11)
> > + else if (IS_ALDERLAKE_P(dev_priv) || IS_DISPLAY_VER(dev_priv, 11,
> > 12))
> > return phy <= PHY_B;
> > else
> > return false;
> > --
> > 2.25.1
>
> Thanks and Regards,
> Arun R Murthy
>
Re: [Intel-gfx] [PATCH] drm/i915/pvc: Adjust EU per SS according to HAS_ONE_EU_PER_FUSE_BIT()
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Friday, June 10, 2022 4:08 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/pvc: Adjust EU per SS according to
> HAS_ONE_EU_PER_FUSE_BIT()
>
> If we're treating each bit in the EU fuse register as a single EU instead of a
> pair of EUs, then that also cuts the number of potential EUs per subslice in
> half.
>
> Fixes: 5ac342ef84d7 ("drm/i915/pvc: Add SSEU changes")
> Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
> b/drivers/gpu/drm/i915/gt/intel_sseu.c
> index 7ef75f0d9c9e..c6d3050604c8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_sseu.c
> +++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
> @@ -229,7 +229,7 @@ static void xehp_sseu_info_init(struct intel_gt *gt)
>*/
> intel_sseu_set_info(sseu, 1,
> 32 * max(num_geometry_regs,
> num_compute_regs),
> - 16);
> + HAS_ONE_EU_PER_FUSE_BIT(gt->i915) ? 8 : 16);
> sseu->has_xehp_dss = 1;
>
> xehp_load_dss_mask(uncore, >geometry_subslice_mask,
> --
> 2.35.3
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg2: Enable DC5
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, May 20, 2022 4:11 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Vudum,
> Lakshminarayana
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dg2: Enable DC5
>
> On Fri, May 20, 2022 at 05:11:22PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/dg2: Enable DC5
> > URL : https://patchwork.freedesktop.org/series/104233/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_11681 -> Patchwork_104233v1
> >
> >
> > Summary
> > ---
> >
> > **FAILURE**
> >
> > Serious unknown changes coming with Patchwork_104233v1 absolutely
> need to be
> > verified manually.
> >
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_104233v1, please notify your bug team 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_104233v1/index.html
> >
> > Participating hosts (46 -> 44)
> > --
> >
> > Missing(2): bat-dg2-8 fi-rkl-11600
> >
> > Possible new issues
> > ---
> >
> > Here are the unknown changes that may have been introduced in
> Patchwork_104233v1:
> >
> > ### IGT changes ###
> >
> > Possible regressions
> >
> > * igt@fbdev@read:
> > - fi-icl-u2: [PASS][1] -> [DMESG-WARN][2]
> >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11681/fi-icl-
> u2/igt@fb...@read.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104233v1/fi-icl-u2/
> > igt@fb...@read.html
>
> It looks like this is an error coming from a bluetooth driver, not related to
> graphics:
>
><3> [26.916574] Bluetooth: hci0: Reading Intel version command failed (-
> 110)
><4> [26.916689] general protection fault, probably for non-canonical
> address 0x6b6b6b6b6b6b6b6b: [#1] PREEMPT SMP NOPTI
><4> [26.916726] CPU: 2 PID: 99 Comm: kworker/2:2 Not tainted 5.18.0-rc7-
> Patchwork_104233v1-gba369855d857+ #1
><4> [26.916731] Hardware name: Intel Corporation Ice Lake Client
> Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS
> ICLSFWR1.R00.3183.A00.1905020411 05/02/2019
><4> [26.916737] Workqueue: events hci_cmd_timeout [bluetooth]
><4> [26.916755] RIP: 0010:hci_cmd_timeout+0x30/0xa0 [bluetooth]
><4> [26.916806] Code: ff ff 53 48 8b 87 10 05 00 00 48 89 fb 48 85 c0 74 63
> 48 8b 80 b8 00 00 00 48 8d b5 a0 00 00 00 48 85 ed 48 c7 c7 c8 6c 38 a0 <0f>
> b7 10 48 c7 c0 53 38 38 a0 48 0f 44 f0 e8 91 13 06 00 48 8b 83
><4> [26.916814] RSP: 0018:c9ae3e50 EFLAGS: 00010286
><4> [26.916818] RAX: 6b6b6b6b6b6b6b6b RBX: 88810ef5aac8 RCX:
>
><4> [26.916821] RDX: 0001 RSI: 88810ef5a0a0 RDI:
> a0386cc8
><4> [26.916825] RBP: 88810ef5a000 R08: 88810700ba38 R09:
> fffe
><4> [26.916828] R10: 0001 R11: dfbbfb17 R12:
> 88849fb3afc0
><4> [26.916832] R13: 88849fb3fc00 R14: R15:
> 88849fb3fc05
><4> [26.916835] FS: () GS:88849fb0()
> knlGS:
><4> [26.916839] CS: 0010 DS: ES: CR0: 80050033
><4> [26.916842] CR2: 7fcc6837e1a0 CR3: 06612006 CR4:
> 00770ee0
><4> [26.916846] PKRU: 5554
><4> [26.916848] Call Trace:
><4> [26.916850]
><4> [26.916852] process_one_work+0x272/0x5c0
><4> [26.916857] worker_thread+0x37/0x370
><4> [26.916861] ? process_one_work+0x5c0/0x5c0
><4> [26.916864] kthread+0xed/0x120
><4> [26.916867] ? kthread_complete_and_exit+0x20/0x20
><4> [26.916870] ret_from_fork+0x1f/0x30
><4> [26.916875]
>
> Looks like this might be
> https://gitlab.freedesktop.org/drm/intel/-/issues/4890 ?
Yeah seems like it.
@Vudum, Lakshminarayana should I resend the series?
Anusha
> >
> >
> > Suppressed
> >
> > The following results come from untrusted machines, tests, or statuses.
> > They do not affect the overall result.
> >
> > * igt@kms_busy@basic@modeset:
> > - {bat-dg2-9}:
Re: [Intel-gfx] [PATCH] drm/i915/d12+: Disable DMC firmware flip queue handlers
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, May 11, 2022 12:19 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/d12+: Disable DMC firmware flip queue
> handlers
>
> Based on a bspec update the DMC firmware's flip queue handling events
> need to be disabled before enabling DC5/6. i915 doesn't use the flip queue
> feature atm, so disable it already after loading the firmware.
> This removes some overhead of the event handler which runs at a 1 kHz
> frequency.
>
> Bspec: 49193, 72486, 72487
>
> Signed-off-by: Imre Deak
Thanks for the patch.
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 89 ++-
> drivers/gpu/drm/i915/display/intel_dmc_regs.h | 74 +++
> 2 files changed, 162 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 257cf662f9f4b..37e58b056cfb7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -244,9 +244,14 @@ struct stepping_info {
> char substepping;
> };
>
> +static bool intel_dmc_has_fw_payload(struct drm_i915_private *i915, int
> +dmc_id) {
> + return i915->dmc.dmc_info[dmc_id].payload;
> +}
> +
> bool intel_dmc_has_payload(struct drm_i915_private *i915) {
> - return i915->dmc.dmc_info[DMC_FW_MAIN].payload;
> + return intel_dmc_has_fw_payload(i915, DMC_FW_MAIN);
> }
>
> static const struct stepping_info *
> @@ -268,6 +273,81 @@ static void gen9_set_dc_state_debugmask(struct
> drm_i915_private *dev_priv)
> intel_de_posting_read(dev_priv, DC_STATE_DEBUG); }
>
> +static void
> +disable_simple_flip_queue_event(struct drm_i915_private *i915,
> + i915_reg_t ctl_reg, i915_reg_t htp_reg) {
> + u32 event_ctl;
> + u32 event_htp;
> +
> + event_ctl = intel_de_read(i915, ctl_reg);
> + event_htp = intel_de_read(i915, htp_reg);
> + if (event_ctl != (DMC_EVT_CTL_ENABLE |
> + DMC_EVT_CTL_RECURRING |
> + REG_FIELD_PREP(DMC_EVT_CTL_TYPE_MASK,
> + DMC_EVT_CTL_TYPE_EDGE_0_1) |
> + REG_FIELD_PREP(DMC_EVT_CTL_EVENT_ID_MASK,
> +
> DMC_EVT_CTL_EVENT_ID_CLK_MSEC)) ||
> + !event_htp) {
> + drm_dbg_kms(>drm,
> + "Unexpected DMC event configuration (control
> %08x htp %08x)\n",
> + event_ctl, event_htp);
> + return;
> + }
> +
> + intel_de_write(i915, ctl_reg,
> +REG_FIELD_PREP(DMC_EVT_CTL_TYPE_MASK,
> + DMC_EVT_CTL_TYPE_EDGE_0_1) |
> +REG_FIELD_PREP(DMC_EVT_CTL_EVENT_ID_MASK,
> + DMC_EVT_CTL_EVENT_ID_FALSE));
> + intel_de_write(i915, htp_reg, 0);
> +}
> +
> +static bool
> +get_simple_flip_queue_event_regs(struct drm_i915_private *i915, int
> dmc_id,
> + i915_reg_t *ctl_reg, i915_reg_t *htp_reg) {
> + switch (dmc_id) {
> + case DMC_FW_MAIN:
> + if (DISPLAY_VER(i915) == 12) {
> + *ctl_reg = DMC_EVT_CTL(dmc_id, 3);
> + *htp_reg = DMC_EVT_HTP(dmc_id, 3);
> +
> + return true;
> + }
> + break;
> + default:
> + if (IS_DG2(i915)) {
> + *ctl_reg = DMC_EVT_CTL(dmc_id, 2);
> + *htp_reg = DMC_EVT_HTP(dmc_id, 2);
> +
> + return true;
> + }
> + break;
> + }
> +
> + return false;
> +}
> +
> +static void
> +disable_all_simple_flip_queue_events(struct drm_i915_private *i915) {
> + int dmc_id;
> +
> + for (dmc_id = 0; dmc_id < DMC_FW_MAX; dmc_id++) {
> + i915_reg_t ctl_reg;
> + i915_reg_t htp_reg;
> +
> + if (!intel_dmc_has_fw_payload(i915, dmc_id))
> + continue;
> +
> + if (!get_simple_flip_queue_event_regs(i915, dmc_id,
> _reg, _reg))
> + continue;
> +
> + disable_simple_flip_queue_event(i915, ctl_reg, htp_reg);
> + }
> +}
> +
> /**
> * intel_dmc_load_program() - write the firmware from memory to register.
> * @dev_priv: i915 drm device.
> @@ -308,6 +388,13 @@ void intel_dmc_load_program(struct
> drm_i915_private *dev_priv)
> dev_priv->dmc.dc_state = 0;
>
> gen9_set_dc_state_debugmask(dev_priv);
> +
> + /*
> + * Flip queue events need to be disabled before enabling DC5/6.
> + * i915 doesn't use the flip queue feature, so disable it already
> + * here.
> + */
> + disable_all_simple_flip_queue_events(dev_priv);
> }
>
> void assert_dmc_loaded(struct drm_i915_private *i915) diff --git
> a/drivers/gpu/drm/i915/display/intel_dmc_regs.h
>
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
> -Original Message-
> From: De Marchi, Lucas
> Sent: Tuesday, May 3, 2022 5:31 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Tue, May 03, 2022 at 05:13:46PM -0700, Anusha Srivatsa wrote:
> >Bspec has added some steps that check forDMC MMIO range before
> >programming them
> >
> >v2: Fix for CI
> >v3: move register defines to .h (Anusha)
> >- Check MMIO restrictions per pipe
> >- Add MMIO restricton for v1 dmc header as well (Lucas)
> >v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
> >- clean up sanity check logic.(Lucas)
> >- Add MMIO range for RKL as well.(Anusha)
> >
> >BSpec: 49193
> >
> >Cc:
> >Cc: Lucas De Marchi
> >Signed-off-by: Anusha Srivatsa
> >---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 43 +++
> > drivers/gpu/drm/i915/display/intel_dmc_regs.h | 18 +++-
> > 2 files changed, 60 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >index 257cf662f9f4..e37ba75e68da 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >@@ -374,6 +374,44 @@ static void dmc_set_fw_offset(struct intel_dmc
> *dmc,
> > }
> > }
> >
> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
> u32 *mmioaddr,
> >+ u32 mmio_count, int header_ver, u8
> dmc_id) {
> >+struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
> dmc);
> >+u32 start_range, end_range;
> >+int i;
> >+
> >+if (dmc_id >= DMC_FW_MAX || dmc_id < DMC_FW_MAIN) {
>
> dmc_id is unsigned and DMC_FW_MAIN is 0. dmc_id < DMC_FW_MAIN can't
> ever possibly happen so you can remove it.
>
> >+drm_warn(>drm, "Unsupported firmware id %u\n",
> dmc_id);
> >+return false;
> >+}
> >+
> >+if (header_ver == 1) {
> >+start_range = DMC_MMIO_START_RANGE;
> >+end_range = DMC_MMIO_END_RANGE;
> >+} else if (dmc_id == DMC_FW_MAIN) {
> >+start_range = TGL_MAIN_MMIO_START;
> >+end_range = TGL_MAIN_MMIO_END;
> >+} else if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
>
> } else if (DISPLAY_VER(i915) >= 13) {
>
> ?
>
> >+start_range = ADLP_PIPE_MMIO_START;
> >+end_range = ADLP_PIPE_MMIO_END;
> >+} else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
> IS_ALDERLAKE_S(i915) ||
> >+ IS_ROCKETLAKE(i915)) {
>
> } else if (DISPLAY_VER(i915) >= 12) {
>
> ?
>
> maintaining the if/else ladder fine grained by platform is somewhat painful.
Agreed.
> >+start_range = TGL_PIPE_MMIO_START(dmc_id);
> >+end_range = TGL_PIPE_MMIO_END(dmc_id);
> >+} else {
> >+drm_warn(>drm, "Unknown mmio range for sanity
> check");
> >+return false;
> >+}
> >+
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < start_range || mmioaddr[i] > end_range)
> >+return false;
> >+}
> >+
> >+return true;
> >+}
> >+
> > static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
> >const struct intel_dmc_header_base
> *dmc_header,
> >size_t rem_size, u8 dmc_id)
> >@@ -443,6 +481,11 @@ static u32 parse_dmc_fw_header(struct intel_dmc
> *dmc,
> > return 0;
> > }
> >
> >+if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count,
> dmc_header->header_ver, dmc_id)) {
> >+drm_err(>drm, "DMC firmware has Wrong MMIO
> Addresses\n");
> >+return 0;
> >+}
> >+
> > for (i = 0; i < mmio_count; i++) {
> > dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
> > dmc_info->mmiodata[i] = mmiodata[i]; diff --git
> >a/drivers/gpu/drm/i915/display/intel_dmc_regs.h
> >b/drivers/gpu/drm/i915/display/intel_dmc_regs.h
> >index d65e698832eb..67e14eb96a7a 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc_regs.h
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc_regs.h
> >@@ -16,7 +16,23 @@
> > #define DMC_LAST_WRITE _MMIO(0x8F034)
> > #define DMC_LAST_WRITE_VALUE0xc003b400
&g
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
> -Original Message-
> From: De Marchi, Lucas
> Sent: Friday, April 29, 2022 1:50 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Fri, Apr 29, 2022 at 01:39:03PM -0700, Anusha Srivatsa wrote:
> >
> >
> >> -Original Message-
> >> From: De Marchi, Lucas
> >> Sent: Tuesday, April 26, 2022 10:42 PM
> >> To: Srivatsa, Anusha
> >> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> >> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
> >>
> >> On Tue, Apr 26, 2022 at 05:35:09PM -0700, Anusha Srivatsa wrote:
> >> >Bspec has added some steps that check forDMC MMIO range before
> >> >programming them
> >> >
> >> >v2: Fix for CI
> >> >v3: move register defines to .h (Anusha)
> >> >- Check MMIO restrictions per pipe
> >> >- Add MMIO restricton for v1 dmc header as well (Lucas)
> >> >
> >> >BSpec: 49193
> >> >
> >> >Cc:
> >> >Cc: Lucas De Marchi
> >> >Signed-off-by: Anusha Srivatsa
> >> >---
> >> > drivers/gpu/drm/i915/display/intel_dmc.c | 48 ---
> >> > drivers/gpu/drm/i915/display/intel_dmc_regs.h | 31
> >> > 2 files changed, 72 insertions(+), 7 deletions(-)
> >> >
> >> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >index 257cf662f9f4..ac7896835bfa 100644
> >> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >@@ -97,13 +97,6 @@ MODULE_FIRMWARE(SKL_DMC_PATH);
> >> > #define BXT_DMC_MAX_FW_SIZE 0x3000
> >> > MODULE_FIRMWARE(BXT_DMC_PATH);
> >> >
> >> >-#define DMC_DEFAULT_FW_OFFSET0x
> >> >-#define PACKAGE_MAX_FW_INFO_ENTRIES 20
> >> >-#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
> >> >-#define DMC_V1_MAX_MMIO_COUNT8
> >> >-#define DMC_V3_MAX_MMIO_COUNT20
> >> >-#define DMC_V1_MMIO_START_RANGE 0x8
> >> >-
> >> > struct intel_css_header {
> >> > /* 0x09 for DMC */
> >> > u32 module_type;
> >> >@@ -374,6 +367,43 @@ static void dmc_set_fw_offset(struct intel_dmc
> >> *dmc,
> >> > }
> >> > }
> >> >
> >> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
> >> u32 *mmioaddr,
> >> >+u32 mmio_count, int header_ver, u8
> >> dmc_id) {
> >> >+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
> >> dmc);
> >> >+ int i;
> >> >+
> >> >+ if (header_ver == 1) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
> >> mmioaddr[i] > DMC_MMIO_END_RANGE)
> >> >+ return false;
> >> >+ }
> >>
> >> return missing here
> >>
> >> >+ }
> >> >+
> >> >+ /* Main DMC MMIO check */
> >> >+ if (dmc_id == DMC_FW_MAIN) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
> >> || mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
> >> >+ return false;
> >> >+ }
> >> >+ }
> >> >+
> >> >+ /* Pipe DMC MMIO check */
> >> >+ if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (mmioaddr[i] < ADLP_PIPE_MMIO_START &&
> >> mmioaddr[i] > ADLP_PIPE_MMIO_END)
> >> >+ return false;
> >> >+ }
> >>
> >> for DG2, main should use TGL_DMC_MMIO_START? and then fail here
> >> because of another missing return above?
> >>
> >> >+ } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
> >> IS_ALDERLAKE_S(i915)) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
> >> || mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
> >> >+ r
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
> -Original Message-
> From: De Marchi, Lucas
> Sent: Tuesday, April 26, 2022 10:42 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Tue, Apr 26, 2022 at 05:35:09PM -0700, Anusha Srivatsa wrote:
> >Bspec has added some steps that check forDMC MMIO range before
> >programming them
> >
> >v2: Fix for CI
> >v3: move register defines to .h (Anusha)
> >- Check MMIO restrictions per pipe
> >- Add MMIO restricton for v1 dmc header as well (Lucas)
> >
> >BSpec: 49193
> >
> >Cc:
> >Cc: Lucas De Marchi
> >Signed-off-by: Anusha Srivatsa
> >---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 48 ---
> > drivers/gpu/drm/i915/display/intel_dmc_regs.h | 31
> > 2 files changed, 72 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >index 257cf662f9f4..ac7896835bfa 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >@@ -97,13 +97,6 @@ MODULE_FIRMWARE(SKL_DMC_PATH);
> > #define BXT_DMC_MAX_FW_SIZE 0x3000
> > MODULE_FIRMWARE(BXT_DMC_PATH);
> >
> >-#define DMC_DEFAULT_FW_OFFSET 0x
> >-#define PACKAGE_MAX_FW_INFO_ENTRIES 20
> >-#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
> >-#define DMC_V1_MAX_MMIO_COUNT 8
> >-#define DMC_V3_MAX_MMIO_COUNT 20
> >-#define DMC_V1_MMIO_START_RANGE 0x8
> >-
> > struct intel_css_header {
> > /* 0x09 for DMC */
> > u32 module_type;
> >@@ -374,6 +367,43 @@ static void dmc_set_fw_offset(struct intel_dmc
> *dmc,
> > }
> > }
> >
> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
> u32 *mmioaddr,
> >+ u32 mmio_count, int header_ver, u8
> dmc_id) {
> >+struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
> dmc);
> >+int i;
> >+
> >+if (header_ver == 1) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
> mmioaddr[i] > DMC_MMIO_END_RANGE)
> >+return false;
> >+}
>
> return missing here
>
> >+}
> >+
> >+/* Main DMC MMIO check */
> >+if (dmc_id == DMC_FW_MAIN) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
> || mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
> >+return false;
> >+}
> >+}
> >+
> >+/* Pipe DMC MMIO check */
> >+if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < ADLP_PIPE_MMIO_START &&
> mmioaddr[i] > ADLP_PIPE_MMIO_END)
> >+return false;
> >+}
>
> for DG2, main should use TGL_DMC_MMIO_START? and then fail here
> because of another missing return above?
>
> >+} else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
> IS_ALDERLAKE_S(i915)) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
> || mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
> >+return false;
>
> this is handling DMC_FW_MAIN twice.
>
>
> Maybe something like this:
>
> u32 start, end;
>
> if (header_ver == 1) {
> start = DMC_MMIO_START_RANGE;
> end = DMC_MMIO_END_RANGE;
> } else if (dmc_id == DMC_FW_MAIN || IS_TIGERLAKE(i915) ||
> IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
> start = TGL_DMC_MMIO_START(dmc_id);
> end = TGL_DMC_MMIO_END(dmc_id);
> } else if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> start = ADLP_PIPE_MMIO_START;
> end = ADLP_PIPE_MMIO_END;
> } else {
> drm_warn(>drm, "Unknown mmio range for sanity
> check");
> return false;
> }
>
> for (i = 0; i < mmio_count; i++)
> if (mmioaddr[i] < start || mmioaddr[i] > end)
> return false;
>
> return true;
>
>
> ... untested, and may need tweaks depending on the answer to the question
> above on what range to use
Re: [Intel-gfx] [PATCH] drm/i915: Disable DC5 before going to DC9
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, April 20, 2022 12:09 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vivi, Rodrigo ; Deak, Imre
> ; Gupta, Anshuman ;
> Srivatsa, Anusha
> Subject: [PATCH] drm/i915: Disable DC5 before going to DC9
>
> According to BSPec:
> Sequence to Allow DC9:
> 1. Follow Sequence to Disallow DC5.
>
> which is:
> Sequence to Disallow DC5 and DC6
> Set DC_STATE_EN Dynamic DC State Enable = "Disable".
>
> I understand that we haven't had any issue so far. But since
> DC9 is a software thing, it is better to disable DC5 before to avoid any
> conflict.
> And respect the spec to avoid potential future issues.
>
> Cc: Imre Deak
> Cc: Anshuman Gupta
> Cc: Anusha Srivatsa
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 6a5695008f7c..b3cf5182044f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -883,6 +883,9 @@ static void bxt_enable_dc9(struct drm_i915_private
> *dev_priv) {
> assert_can_enable_dc9(dev_priv);
^ We are already checking if DC5 is enabled. If enabled then don't enable DC9.
SO the change should be- if driver cannot enableDC9 because DC5 is enabled then
go ahead and disable DC5.
Anusha
> + /* Disable DC5 before enabling DC9 */
> + gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> +
> drm_dbg_kms(_priv->drm, "Enabling DC9\n");
> /*
>* Power sequencer reset is not needed on
> --
> 2.34.1
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmc: Load DMC on DG2 (rev4)
HI,
The result here says SUCCESS but closer look shows that it never ran on any
DG2. Wanted to know if something went wrong at the system side and if it needs
to be revived. The patch is simply loading DMC and shouldn’t cause the system
to not boot up at all.
Any info in this regard will be very useful.
Thanks,
Anusha
From: Patchwork
Sent: Thursday, April 14, 2022 11:04 AM
To: Srivatsa, Anusha
Cc: intel-gfx@lists.freedesktop.org
Subject: ✓ Fi.CI.BAT: success for drm/i915/dmc: Load DMC on DG2 (rev4)
Patch Details
Series:
drm/i915/dmc: Load DMC on DG2 (rev4)
URL:
https://patchwork.freedesktop.org/series/102630/
State:
success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/index.html
CI Bug Log - changes from CI_DRM_11500 -> Patchwork_102630v4
Summary
SUCCESS
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/index.html
Participating hosts (48 -> 45)
Additional (2): bat-adlm-1 fi-pnv-d510
Missing (5): bat-dg2-8 fi-bsw-cyan fi-icl-u2 bat-dg2-9 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_102630v4 that come from known issues:
IGT changes
Issues hit
* igt@i915_selftest@live@execlists:
* fi-bsw-nick:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11500/fi-bsw-nick/igt@i915_selftest@l...@execlists.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/fi-bsw-nick/igt@i915_selftest@l...@execlists.html>
(i915#2940<https://gitlab.freedesktop.org/drm/intel/issues/2940>)
* igt@i915_selftest@live@hangcheck:
* fi-snb-2600:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11500/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html>
(i915#3921<https://gitlab.freedesktop.org/drm/intel/issues/3921>)
* igt@i915_selftest@live@requests:
* fi-blb-e6850:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11500/fi-blb-e6850/igt@i915_selftest@l...@requests.html>
->
DMESG-FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/fi-blb-e6850/igt@i915_selftest@l...@requests.html>
(i915#4528<https://gitlab.freedesktop.org/drm/intel/issues/4528>)
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
* fi-pnv-d510: NOTRUN ->
SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html>
(fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
i915#5341<https://gitlab.freedesktop.org/drm/intel/issues/5341>)
* igt@prime_vgem@basic-userptr:
* fi-pnv-d510: NOTRUN ->
SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/fi-pnv-d510/igt@prime_v...@basic-userptr.html>
(fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +39 similar
issues
* igt@runner@aborted:
* fi-bsw-nick: NOTRUN ->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/fi-bsw-nick/igt@run...@aborted.html>
(fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
i915#3428<https://gitlab.freedesktop.org/drm/intel/issues/3428> /
i915#4312<https://gitlab.freedesktop.org/drm/intel/issues/4312>)
* fi-bdw-5557u: NOTRUN ->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/fi-bdw-5557u/igt@run...@aborted.html>
(i915#4312<https://gitlab.freedesktop.org/drm/intel/issues/4312>)
* fi-blb-e6850: NOTRUN ->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v4/fi-blb-e6850/igt@run...@aborted.html>
(fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
i915#2403<https://gitlab.freedesktop.org/drm/intel/issues/2403> /
i915#4312<https://gitlab.freedesktop.org/drm/intel/issues/4312>)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
Build changes
* Linux: CI_DRM_11500 -> Patchwork_102630v4
CI-20190529: 20190529
CI_DRM_11500: 91c829bc09be35f3e9a6674274969c72f60b5e22 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6420: a3885810ccc0ce9e6552a20c910a0a322eca466c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_102630v4: 91c829bc09be35f3e9a6674274969c72f60b5e22 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
16f68d87628e drm/i915/dmc: Load DMC on DG2
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dmc: Load DMC on DG2
From: Patchwork
Sent: Wednesday, April 13, 2022 1:01 PM
To: Srivatsa, Anusha
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915/dmc: Load DMC on DG2
Patch Details
Series:
drm/i915/dmc: Load DMC on DG2
URL:
https://patchwork.freedesktop.org/series/102630/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/index.html
CI Bug Log - changes from CI_DRM_11496 -> Patchwork_102630v1
Summary
FAILURE
Serious unknown changes coming with Patchwork_102630v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102630v1, please notify your bug team 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_102630v1/index.html
Participating hosts (50 -> 46)
Additional (1): fi-pnv-d510
Missing (5): fi-cml-u2 fi-bsw-cyan fi-icl-u2 bat-hsw-1 fi-bdw-samus
Possible new issues
Here are the unknown changes that may have been introduced in
Patchwork_102630v1:
IGT changes
Possible regressions
* igt@i915_selftest@live@hangcheck:
* fi-hsw-4770:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11496/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html>
->
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html>
The failure reported is not because of the changes introduced.
Anusha
Known issues
Here are the changes found in Patchwork_102630v1 that come from known issues:
IGT changes
Issues hit
* igt@kms_busy@basic@modeset:
* fi-tgl-u2:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11496/fi-tgl-u2/igt@kms_busy@ba...@modeset.html>
->
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/fi-tgl-u2/igt@kms_busy@ba...@modeset.html>
(i915#402<https://gitlab.freedesktop.org/drm/intel/issues/402>)
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
* fi-pnv-d510: NOTRUN ->
SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html>
(fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> /
i915#5341<https://gitlab.freedesktop.org/drm/intel/issues/5341>)
* igt@prime_vgem@basic-userptr:
* fi-pnv-d510: NOTRUN ->
SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/fi-pnv-d510/igt@prime_v...@basic-userptr.html>
(fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +39 similar
issues
* igt@runner@aborted:
* fi-bdw-5557u: NOTRUN ->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/fi-bdw-5557u/igt@run...@aborted.html>
(i915#4312<https://gitlab.freedesktop.org/drm/intel/issues/4312>)
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
* fi-bdw-5557u:
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11496/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html>
(i915#146<https://gitlab.freedesktop.org/drm/intel/issues/146>) ->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html>
* igt@i915_pm_rps@basic-api:
* {bat-dg2-9}:
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11496/bat-dg2-9/igt@i915_pm_...@basic-api.html>
->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/bat-dg2-9/igt@i915_pm_...@basic-api.html>
* igt@i915_selftest@live@gt_heartbeat:
* fi-skl-guc:
DMESG-FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11496/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html>
->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html>
* igt@i915_selftest@live@hangcheck:
* fi-snb-2600:
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11496/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html>
(i915#3921<https://gitlab.freedesktop.org/drm/intel/issues/3921>) ->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html>
* igt@kms_busy@basic@flip:
* {bat-adlp-6}:
DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11496/bat-adlp-6/igt@kms_busy@ba...@flip.html>
(i915#3576<https://gitlab.freedesktop.org/drm/intel/issues/3576>) ->
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102630v1/bat-adlp-6/igt@kms_busy@ba...@flip.html>
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
Build changes
* Linux: CI_DRM_11496 -> Patchwork_102630v1
CI-20190529: 20190529
CI_DRM_11496: 6dec7597a5027afe15cf36f
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
> -Original Message-
> From: De Marchi, Lucas
> Sent: Wednesday, April 6, 2022 10:46 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Wed, Apr 06, 2022 at 10:16:55AM -0700, Anusha Srivatsa wrote:
> >
> >
> >> -Original Message-
> >> From: De Marchi, Lucas
> >> Sent: Tuesday, April 5, 2022 11:03 AM
> >> To: Srivatsa, Anusha
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range
> >> restrictions
> >>
> >> On Tue, Apr 05, 2022 at 10:14:29AM -0700, Anusha Srivatsa wrote:
> >> >Bspec has added some steps that check for DMC MMIO range before
> >> >programming them.
> >> >
> >> >v2: Fix for CI failure for v1
> >> >
> >> >Cc: Lucas De Marchi
> >> >Signed-off-by: Anusha Srivatsa
> >> >---
> >> > drivers/gpu/drm/i915/display/intel_dmc.c | 42
> >>
> >> > 1 file changed, 42 insertions(+)
> >> >
> >> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >index 257cf662f9f4..05d8e90854ec 100644
> >> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >> >@@ -103,6 +103,18 @@ MODULE_FIRMWARE(BXT_DMC_PATH);
> >> > #define DMC_V1_MAX_MMIO_COUNT8
> >> > #define DMC_V3_MAX_MMIO_COUNT20
> >> > #define DMC_V1_MMIO_START_RANGE 0x8
> >> >+#define TGL_MAIN_MMIO_START 0x8F000
> >> >+#define TGL_MAIN_MMIO_END0x8
> >> >+#define TGL_PIPEA_MMIO_START 0x92000
> >> >+#define TGL_PIPEA_MMIO_END 0x93FFF
> >> >+#define TGL_PIPEB_MMIO_START 0x96000
> >> >+#define TGL_PIPEB_MMIO_END 0x97FFF
> >> >+#define TGL_PIPEC_MMIO_START 0x9A000
> >> >+#define TGL_PIPEC_MMIO_END 0x9BFFF
> >> >+#define TGL_PIPED_MMIO_START 0x9E000
> >> >+#define TGL_PIPED_MMIO_END 0x9
> >> >+#define ADLP_PIPE_MMIO_START 0x5F000
> >> >+#define ADLP_PIPE_MMIO_END 0x5
> >> >
> >> > struct intel_css_header {
> >> > /* 0x09 for DMC */
> >> >@@ -374,6 +386,30 @@ static void dmc_set_fw_offset(struct intel_dmc
> >> *dmc,
> >> > }
> >> > }
> >> >
> >> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
> >> >+u32 *mmioaddr,
> >> >+u32 mmio_count)
> >> >+{
> >> >+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
> >> dmc);
> >> >+ int i;
> >> >+
> >> >+ if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (!((mmioaddr[i] >= TGL_MAIN_MMIO_START &&
> >> mmioaddr[i] <= TGL_MAIN_MMIO_END) ||
> >> >+ (mmioaddr[i] >= ADLP_PIPE_MMIO_START &&
> >> mmioaddr[i] <= ADLP_PIPE_MMIO_END)))
> >> >+ return false;
> >> >+ }
> >> >+ } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
> >> IS_ALDERLAKE_S(i915))
> >> >+ for (i = 0; i < mmio_count; i++) {
> >> >+ if (!((mmioaddr[i] >= TGL_MAIN_MMIO_START &&
> >> mmioaddr[i] <= TGL_MAIN_MMIO_END) ||
> >> >+ (mmioaddr[i] >= TGL_PIPEA_MMIO_START &&
> >> mmioaddr[i] <= TGL_PIPEA_MMIO_END) ||
> >> >+ (mmioaddr[i] >= TGL_PIPEB_MMIO_START &&
> >> mmioaddr[i] <= TGL_PIPEB_MMIO_END) ||
> >> >+ (mmioaddr[i] >= TGL_PIPEC_MMIO_START &&
> >> mmioaddr[i] <= TGL_PIPEC_MMIO_END) ||
> >> >+ (mmioaddr[i] >= TGL_PIPED_MMIO_START &&
> >> mmioaddr[i] <= TGL_PIPEC_MMIO_END)))
> >> >+ return false;
> >>
> >> wonder if we should check for each pipe DMC range independently
> >> rather than just checking all the ranges.
> > Can convert this to a switch case in that scenario. "If it is PIPE A then
> > it must
>
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
> -Original Message-
> From: De Marchi, Lucas
> Sent: Tuesday, April 5, 2022 11:03 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
>
> On Tue, Apr 05, 2022 at 10:14:29AM -0700, Anusha Srivatsa wrote:
> >Bspec has added some steps that check for DMC MMIO range before
> >programming them.
> >
> >v2: Fix for CI failure for v1
> >
> >Cc: Lucas De Marchi
> >Signed-off-by: Anusha Srivatsa
> >---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 42
>
> > 1 file changed, 42 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >index 257cf662f9f4..05d8e90854ec 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >@@ -103,6 +103,18 @@ MODULE_FIRMWARE(BXT_DMC_PATH);
> > #define DMC_V1_MAX_MMIO_COUNT 8
> > #define DMC_V3_MAX_MMIO_COUNT 20
> > #define DMC_V1_MMIO_START_RANGE 0x8
> >+#define TGL_MAIN_MMIO_START 0x8F000
> >+#define TGL_MAIN_MMIO_END 0x8
> >+#define TGL_PIPEA_MMIO_START0x92000
> >+#define TGL_PIPEA_MMIO_END 0x93FFF
> >+#define TGL_PIPEB_MMIO_START0x96000
> >+#define TGL_PIPEB_MMIO_END 0x97FFF
> >+#define TGL_PIPEC_MMIO_START0x9A000
> >+#define TGL_PIPEC_MMIO_END 0x9BFFF
> >+#define TGL_PIPED_MMIO_START0x9E000
> >+#define TGL_PIPED_MMIO_END 0x9
> >+#define ADLP_PIPE_MMIO_START0x5F000
> >+#define ADLP_PIPE_MMIO_END 0x5
> >
> > struct intel_css_header {
> > /* 0x09 for DMC */
> >@@ -374,6 +386,30 @@ static void dmc_set_fw_offset(struct intel_dmc
> *dmc,
> > }
> > }
> >
> >+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
> >+u32 *mmioaddr,
> >+u32 mmio_count)
> >+{
> >+struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
> dmc);
> >+int i;
> >+
> >+if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
> >+for (i = 0; i < mmio_count; i++) {
> >+if (!((mmioaddr[i] >= TGL_MAIN_MMIO_START &&
> mmioaddr[i] <= TGL_MAIN_MMIO_END) ||
> >+ (mmioaddr[i] >= ADLP_PIPE_MMIO_START &&
> mmioaddr[i] <= ADLP_PIPE_MMIO_END)))
> >+return false;
> >+}
> >+} else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
> IS_ALDERLAKE_S(i915))
> >+for (i = 0; i < mmio_count; i++) {
> >+if (!((mmioaddr[i] >= TGL_MAIN_MMIO_START &&
> mmioaddr[i] <= TGL_MAIN_MMIO_END) ||
> >+ (mmioaddr[i] >= TGL_PIPEA_MMIO_START &&
> mmioaddr[i] <= TGL_PIPEA_MMIO_END) ||
> >+ (mmioaddr[i] >= TGL_PIPEB_MMIO_START &&
> mmioaddr[i] <= TGL_PIPEB_MMIO_END) ||
> >+ (mmioaddr[i] >= TGL_PIPEC_MMIO_START &&
> mmioaddr[i] <= TGL_PIPEC_MMIO_END) ||
> >+ (mmioaddr[i] >= TGL_PIPED_MMIO_START &&
> mmioaddr[i] <= TGL_PIPEC_MMIO_END)))
> >+return false;
>
> wonder if we should check for each pipe DMC range independently rather
> than just checking all the ranges.
Can convert this to a switch case in that scenario. "If it is PIPE A then it
must be within this range". But it will be 2 switches one for DG2 and ADLP and
one for TGL and the rest which have individual ranges for every pipe.
> >+}
> >+return true;
> >+}
> >+
> > static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
> >const struct intel_dmc_header_base
> *dmc_header,
> >size_t rem_size, u8 dmc_id)
> >@@ -443,6 +479,12 @@ static u32 parse_dmc_fw_header(struct intel_dmc
> *dmc,
> > return 0;
> > }
> >
> >+if (dmc_header->header_ver == 3) {
>
> this also needs to be done for ver 2
For v2 though there has been no update about the start range. As in this mmio
range is different from the RAM_MMIO_START range.
Anusha
> Lucas De Marchi
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/dg2: Add preemption changes for Wa_14015141709
Looks good.
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Friday, March 4, 2022 3:47 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 1/2] drm/i915/dg2: Add preemption changes
> for Wa_14015141709
>
> From: Akeem G Abodunrin
>
> Starting with DG2, preemption can no longer be controlled using userspace
> on a per-context basis. Instead, the hardware only allows us to enable or
> disable preemption in a global, system-wide basis. Also, we lose the ability
> to specify the preemption granularity (such as batch-level vs command-level
> vs object-level).
>
> v2 (MattR):
> - Move debugfs interface to a separate patch. (Jani)
>
> Cc: Matt Roper
> Cc: Prathap Kumar Valsan
> Cc: John Harrison
> Cc: Joonas Lahtinen
> Cc: Jani Nikula
> Cc: Tvrtko Ursulin
> Signed-off-by: Akeem G Abodunrin
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index beca8735bae5..f695a9c96c8d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2310,7 +2310,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>FF_DOP_CLOCK_GATE_DISABLE);
> }
>
> - if (IS_GRAPHICS_VER(i915, 9, 12)) {
> + if (HAS_PERCTX_PREEMPT_CTRL(i915)) {
> /*
> FtrPerCtxtPreemptionGranularityControl:skl,bxt,kbl,cfl,cnl,icl,tgl */
> wa_masked_en(wal,
>GEN7_FF_SLICE_CS_CHICKEN1,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 943267393ecb..afefb3bd2714
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1396,6 +1396,9 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915, #define HAS_GUC_DEPRIVILEGE(dev_priv) \
> (INTEL_INFO(dev_priv)->has_guc_deprivilege)
>
> +#define HAS_PERCTX_PREEMPT_CTRL(i915) \
> + ((GRAPHICS_VER(i915) >= 9) && GRAPHICS_VER_FULL(i915) <
> IP_VER(12,
> +55))
> +
> static inline bool run_as_guest(void)
> {
> return !hypervisor_is_type(X86_HYPER_NATIVE);
> --
> 2.34.1
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Add CDCLK checks to atomic check phase (rev3)
Checked the logs, a lot of machines not showing tests results even though
igt_run.txt shows as PASS for most. The boot log shows ACL errors in
/var/log/journal/ , sending the series again.
Anusha
From: Patchwork
Sent: Friday, March 11, 2022 12:55 AM
To: Srivatsa, Anusha
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for Add CDCLK checks to atomic check phase (rev3)
Patch Details
Series:
Add CDCLK checks to atomic check phase (rev3)
URL:
https://patchwork.freedesktop.org/series/101068/
State:
failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/index.html
CI Bug Log - changes from CI_DRM_11350 -> Patchwork_22540
Summary
FAILURE
Serious unknown changes coming with Patchwork_22540 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22540, please notify your bug team 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_22540/index.html
Participating hosts (48 -> 27)
Additional (2): fi-kbl-soraka fi-pnv-d510
Missing (23): fi-rkl-11600 bat-dg1-6 bat-dg1-5 fi-icl-u2 fi-apl-guc bat-rpls-2
shard-dg1 fi-bdw-5557u shard-tglu fi-adl-ddr5 fi-glk-dsi fi-kbl-7500u
fi-ctg-p8600 fi-skl-6700k2 fi-skl-guc fi-cfl-8700k fi-hsw-4200u fi-bsw-cyan
fi-cfl-guc fi-kbl-x1275 fi-cfl-8109u shard-rkl fi-bdw-samus
Possible new issues
Here are the unknown changes that may have been introduced in Patchwork_22540:
IGT changes
Possible regressions
* igt@gem_exec_suspend@basic-s0@smem:
* fi-bsw-nick:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-bsw-nick/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-bsw-nick/igt@gem_exec_suspend@basic...@smem.html>
* fi-glk-j4005:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html>
* fi-rkl-guc:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-rkl-guc/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-rkl-guc/igt@gem_exec_suspend@basic...@smem.html>
* fi-bsw-kefka:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-bsw-kefka/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-bsw-kefka/igt@gem_exec_suspend@basic...@smem.html>
* fi-bsw-n3050:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-bsw-n3050/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-bsw-n3050/igt@gem_exec_suspend@basic...@smem.html>
* fi-bxt-dsi:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-bxt-dsi/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-bxt-dsi/igt@gem_exec_suspend@basic...@smem.html>
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s0@smem:
* {fi-ehl-2}:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html>
* {fi-jsl-1}:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-jsl-1/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-jsl-1/igt@gem_exec_suspend@basic...@smem.html>
* {fi-tgl-dsi}:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/fi-tgl-dsi/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-tgl-dsi/igt@gem_exec_suspend@basic...@smem.html>
* {bat-adlp-6}:
PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11350/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html>
->
INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html>
* igt@runner@aborted:
* {bat-jsl-1}: NOTRUN ->
FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/bat-jsl-1/igt@run...@aborted.html>
Known issues
Here are the changes found in Patchwork_22540 that come from known issues:
IGT changes
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
* fi-hsw-4770: NOTRUN ->
SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22540/fi-hsw-4770/igt@amdg
Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Add cdclk check to atomic check
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, March 3, 2022 1:59 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/cdclk: Add cdclk check to atomic
> check
>
> On Wed, 02 Mar 2022, Anusha Srivatsa wrote:
> > Checking cdclk conditions during atomic check and preparing for commit
> > phase so we can have atomic commit as simple as possible. Add the
> > specific steps to be taken during cdclk changes, prepare for
> > squashing, crawling and modeset scenarios.
> >
> > Rename functions intel_cdclk_can_squash() and
> > intel_cdclk_can_crawl() since they no longer simply check if squashing
> > and crawling can be performed.
>
> IMO the patch is doing too much at once. There's adding parameters (can be
> done separately at first), there's renames (can be done separately
> afterwards), there's functional changes, all in one.
>
> If you got a bisect result pointing at this commit as regressing, would you
> able to easily figure out what went wrong?
Agreed. Splitting would be good.
> Some comments inline too.
>
> BR,
> Jani.
>
> >
> > Cc: Stanislav Lisovskiy
> > Cc: Matt Roper
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c| 169 +++---
> > drivers/gpu/drm/i915/display/intel_cdclk.h| 16 +-
> > .../drm/i915/display/intel_display_power.c| 2 +-
> > 3 files changed, 123 insertions(+), 64 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index fda8b701..04f3f77ef0a8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1700,12 +1700,23 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> > const struct intel_cdclk_config *cdclk_config,
> > enum pipe pipe)
> > {
> > + struct intel_atomic_state *state;
> > + struct intel_cdclk_state *new_cdclk_state;
> > + struct cdclk_steps *cdclk_steps;
> > + struct intel_cdclk_state *cdclk_state;
> > int cdclk = cdclk_config->cdclk;
> > int vco = cdclk_config->vco;
> > + u32 squash_ctl = 0;
> > u32 val;
> > u16 waveform;
> > int clock;
> > int ret;
> > + int i;
> > +
> > + cdclk_state = to_intel_cdclk_state(dev_priv->cdclk.obj.state);
> > + state = cdclk_state->base.state;
> > + new_cdclk_state = intel_atomic_get_new_cdclk_state(state);
> > + cdclk_steps = new_cdclk_state->steps;
> >
> > /* Inform power controller of upcoming frequency change. */
> > if (DISPLAY_VER(dev_priv) >= 11)
> > @@ -1728,40 +1739,43 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> > return;
> > }
> >
> > - if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->cdclk.hw.vco > 0 &&
> vco > 0) {
> > - if (dev_priv->cdclk.hw.vco != vco)
> > + for (i = 0; i < CDCLK_ACTIONS; i++) {
> > + switch (cdclk_steps[i].action) {
> > + case CDCLK_MODESET:
> > + if (DISPLAY_VER(dev_priv) >= 11) {
> > + if (dev_priv->cdclk.hw.vco != 0 &&
> > + dev_priv->cdclk.hw.vco != vco)
> > + icl_cdclk_pll_disable(dev_priv);
> > +
> > + if (dev_priv->cdclk.hw.vco != vco)
> > + icl_cdclk_pll_enable(dev_priv, vco);
> > + } else {
> > + if (dev_priv->cdclk.hw.vco != 0 &&
> > + dev_priv->cdclk.hw.vco != vco)
> > + bxt_de_pll_disable(dev_priv);
> > +
> > + if (dev_priv->cdclk.hw.vco != vco)
> > + bxt_de_pll_enable(dev_priv, vco);
> > + }
> > + clock = cdclk;
> > + break;
> > + case CDCLK_CRAWL:
> > adlp_cdclk_pll_crawl(dev_priv, vco);
> > - } else if (DISPLAY_VER(dev_priv) >= 11) {
> > - if (dev_priv->cdclk.hw.vco != 0 &&
> > - dev_priv->cdclk.hw.vco != vco)
> > - icl_cdclk_pll_disable(dev_priv);
> > -
> > - if (dev_priv->cdclk.
Re: [Intel-gfx] [PATCH] drm/i915/rps/tgl+: Remove RPS interrupt support
> -Original Message-
> From: Intel-gfx On Behalf Of José
> Roberto de Souza
> Sent: Friday, February 18, 2022 1:04 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/rps/tgl+: Remove RPS interrupt
> support
>
> TGL+ and newer platforms don't support RPS up and low interruption
> limits.
> It is not used for broadwell and newer plaforms that supports execlist but
> here making sure that it is explicit not used even in debug scenarios.
>
> BSpec: 33301
> BSpec: 52069
> BSpec: 9520
> HSD: 1405911647
> Cc: Vinay Belgaumkar
> Signed-off-by: José Roberto de Souza
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/gt/intel_rps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index fd95449ed46da..c8124101aada2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -1486,7 +1486,7 @@ void intel_rps_enable(struct intel_rps *rps)
>
> if (has_busy_stats(rps))
> intel_rps_set_timer(rps);
> - else if (GRAPHICS_VER(i915) >= 6)
> + else if (GRAPHICS_VER(i915) >= 6 && GRAPHICS_VER(i915) <= 11)
> intel_rps_set_interrupts(rps);
> else
> /* Ironlake currently uses intel_ips.ko */ {}
> --
> 2.35.1
Re: [Intel-gfx] [PATCH] drm/i915/adl-n: Add PCH Support for Alder Lake N
> -Original Message-
> From: Intel-gfx On Behalf Of Tejas
> Upadhyay
> Sent: Thursday, January 27, 2022 2:35 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/adl-n: Add PCH Support for Alder Lake
> N
>
> Add the PCH ID for ADL-N.
>
> Signed-off-by: Tejas Upadhyay
>
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_pch.c | 1 +
> drivers/gpu/drm/i915/intel_pch.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pch.c
> b/drivers/gpu/drm/i915/intel_pch.c
> index da8f82c2342f..4f7a61d5502e 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -130,6 +130,7 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id)
> case INTEL_PCH_ADP_DEVICE_ID_TYPE:
> case INTEL_PCH_ADP2_DEVICE_ID_TYPE:
> case INTEL_PCH_ADP3_DEVICE_ID_TYPE:
> + case INTEL_PCH_ADP4_DEVICE_ID_TYPE:
> drm_dbg_kms(_priv->drm, "Found Alder Lake PCH\n");
> drm_WARN_ON(_priv->drm,
> !IS_ALDERLAKE_S(dev_priv) &&
> !IS_ALDERLAKE_P(dev_priv));
> diff --git a/drivers/gpu/drm/i915/intel_pch.h
> b/drivers/gpu/drm/i915/intel_pch.h
> index 6bff77521094..6fd20408f7bf 100644
> --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -58,6 +58,7 @@ enum intel_pch {
> #define INTEL_PCH_ADP_DEVICE_ID_TYPE 0x7A80
> #define INTEL_PCH_ADP2_DEVICE_ID_TYPE0x5180
> #define INTEL_PCH_ADP3_DEVICE_ID_TYPE0x7A00
> +#define INTEL_PCH_ADP4_DEVICE_ID_TYPE0x5480
> #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
> #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
> #define INTEL_PCH_QEMU_DEVICE_ID_TYPE0x2900 /* qemu q35
> has 2918 */
> --
> 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/dg1: Update DMC_DEBUG3 register
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, February 10, 2022 10:51 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dg1: Update DMC_DEBUG3 register
>
> On Thu, Feb 10, 2022 at 08:44:30AM -0800, Anusha Srivatsa wrote:
> > DMC_DEBUGU3 changes from DG1+
>
> This looks to be the same thing as the patch that Chuansheng Liu sent:
>
> https://patchwork.freedesktop.org/patch/473272/?series=99942=1
Yes it is :-/ He sent the patch before mine. So this is void now.
Anusha
>
> Matt
>
> >
> > Bspec: 49788
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_display_debugfs.c | 6 --
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 2 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index f4de004d470f..87fc4b9b7b93 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -474,8 +474,10 @@ static int i915_dmc_info(struct seq_file *m, void
> *unused)
> > * reg for DC3CO debugging and validation,
> > * but TGL DMC f/w is using DMC_DEBUG3 reg for DC3CO
> counter.
> > */
> > - seq_printf(m, "DC3CO count: %d\n",
> > - intel_de_read(dev_priv, DMC_DEBUG3));
> > + if (IS_DGFX(dev_priv))
> > + seq_printf(m, "DC3CO count: %d\n",
> intel_de_read(dev_priv, DG1_DMC_DEBUG3));
> > + else
> > + seq_printf(m, "DC3CO count: %d\n",
> intel_de_read(dev_priv,
> > +DMC_DEBUG3));
> > } else {
> > dc5_reg = IS_BROXTON(dev_priv) ?
> BXT_DMC_DC3_DC5_COUNT :
> > SKL_DMC_DC3_DC5_COUNT;
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 87c92314ee26..802962e3977c
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5633,6 +5633,7 @@
> > #define DG1_DMC_DEBUG_DC5_COUNT_MMIO(0x134154)
> >
> > #define DMC_DEBUG3 _MMIO(0x101090)
> > +#define DG1_DMC_DEBUG3 _MMIO(0x13415C)
> >
> > /* Display Internal Timeout Register */
> > #define RM_TIMEOUT _MMIO(0x42060)
> > --
> > 2.25.1
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
Re: [Intel-gfx] [v2] drm/i915/rpl-s: Add stepping info
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, January 24, 2022 5:06 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [v2] drm/i915/rpl-s: Add stepping info
>
> On Mon, Jan 24, 2022 at 04:16:35PM -0800, Anusha Srivatsa wrote:
> > Add stepping-substepping info in
> > accordance to BSpec changes.
> > Though it looks weird, the revision ID for the newer stepping is
> > indeed backwards and is in accordance to the spec.
> >
> > v2: Rearrange the platforms in logical order (Matt)
> >
> > Bspec: 53655
> > Cc: Roper, Matthew D
>
> Git tools like send-email get very confused when they try to parse "Last,
> First" name ordering. It's best to use "First Last" with no comma to avoid
> problems.
Yeah, realized it immediately after hitting send :-/
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/intel_step.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_step.c
> > b/drivers/gpu/drm/i915/intel_step.c
> > index a4b16b9e2e55..be055eb0b610 100644
> > --- a/drivers/gpu/drm/i915/intel_step.c
> > +++ b/drivers/gpu/drm/i915/intel_step.c
> > @@ -122,6 +122,11 @@ static const struct intel_step_info
> dg2_g11_revid_step_tbl[] = {
> > [0x5] = { COMMON_GT_MEDIA_STEP(B1), .display_step = STEP_C0 },
> };
> >
> > +static const struct intel_step_info adls_rpls_revids[] = {
> > + [0x4] = { COMMON_GT_MEDIA_STEP(D0), .display_step = STEP_D0 },
> > + [0xC] = { COMMON_GT_MEDIA_STEP(D0), .display_step = STEP_C0 },
> };
> > +
> > void intel_step_init(struct drm_i915_private *i915) {
> > const struct intel_step_info *revids = NULL; @@ -129,6 +134,7 @@
> > void intel_step_init(struct drm_i915_private *i915)
> > int revid = INTEL_REVID(i915);
> > struct intel_step_info step = {};
> >
> > +
>
> Unwanted extra line here, but we can just fix that up (and the cc line
> above) while applying the patch.
>
> Reviewed-by: Matt Roper
Thanks!
Anusha
> > if (IS_DG2_G10(i915)) {
> > revids = dg2_g10_revid_step_tbl;
> > size = ARRAY_SIZE(dg2_g10_revid_step_tbl);
> > @@ -141,6 +147,9 @@ void intel_step_init(struct drm_i915_private *i915)
> > } else if (IS_ALDERLAKE_P(i915)) {
> > revids = adlp_revids;
> > size = ARRAY_SIZE(adlp_revids);
> > + } else if (IS_ADLS_RPLS(i915)) {
> > +revids = adls_rpls_revids;
> > +size = ARRAY_SIZE(adls_rpls_revids);
> > } else if (IS_ALDERLAKE_S(i915)) {
> > revids = adls_revids;
> > size = ARRAY_SIZE(adls_revids);
> > --
> > 2.25.1
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
Re: [Intel-gfx] [PATCH] drm/i915/display: Move cdclk checks to atomic check
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, December 21, 2021 1:03 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Cc: Syrjala, Ville
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Move cdclk checks to
> atomic check
>
> On Fri, 17 Dec 2021, Anusha Srivatsa wrote:
> > Checking cdclk conditions during atomic check and preparing for commit
> > phase so we can have atomic commit as simple as possible. Add the
> > specific steps to be taken during cdclk changes, prepare for
> > squashing, crawling and modeset scenarios.
> > Rename functions intel_cdclk_can_squash() and
> > intel_cdclk_can_crawl() since they no longer simply check if squashing
> > and crawling can be performed.
> >
> > Cc: Matt Roper
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c| 130 +++---
> > drivers/gpu/drm/i915/display/intel_cdclk.h| 3 +-
> > .../drm/i915/display/intel_display_power.c| 2 +-
> > drivers/gpu/drm/i915/i915_drv.h | 13 ++
> > 4 files changed, 96 insertions(+), 52 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 249f81a80eb7..4a5ddc202c05 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1698,12 +1698,15 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> > const struct intel_cdclk_config *cdclk_config,
> > enum pipe pipe)
> > {
> > + struct cdclk_steps *cdclk_steps = dev_priv->cdclk.steps;
> > int cdclk = cdclk_config->cdclk;
> > int vco = cdclk_config->vco;
> > + u32 squash_ctl = 0;
> > u32 val;
> > u16 waveform;
> > int clock;
> > int ret;
> > + int i;
> >
> > /* Inform power controller of upcoming frequency change. */
> > if (DISPLAY_VER(dev_priv) >= 11)
> > @@ -1727,40 +1730,43 @@ static void bxt_set_cdclk(struct
> drm_i915_private *dev_priv,
> > return;
> > }
> >
> > - if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->cdclk.hw.vco > 0 &&
> vco > 0) {
> > - if (dev_priv->cdclk.hw.vco != vco)
> > + for (i = 0; i < CDCLK_ACTIONS; i++) {
> > + switch (cdclk_steps[i].action) {
> > + case CDCLK_MODESET:
> > + if (DISPLAY_VER(dev_priv) >= 11) {
> > + if (dev_priv->cdclk.hw.vco != 0 &&
> > + dev_priv->cdclk.hw.vco != vco)
> > + icl_cdclk_pll_disable(dev_priv);
> > +
> > + if (dev_priv->cdclk.hw.vco != vco)
> > + icl_cdclk_pll_enable(dev_priv, vco);
> > + } else {
> > + if (dev_priv->cdclk.hw.vco != 0 &&
> > + dev_priv->cdclk.hw.vco != vco)
> > + bxt_de_pll_disable(dev_priv);
> > +
> > + if (dev_priv->cdclk.hw.vco != vco)
> > + bxt_de_pll_enable(dev_priv, vco);
> > + }
> > + clock = cdclk;
> > + break;
> > + case CDCLK_CRAWL:
> > adlp_cdclk_pll_crawl(dev_priv, vco);
> > - } else if (DISPLAY_VER(dev_priv) >= 11) {
> > - if (dev_priv->cdclk.hw.vco != 0 &&
> > - dev_priv->cdclk.hw.vco != vco)
> > - icl_cdclk_pll_disable(dev_priv);
> > -
> > - if (dev_priv->cdclk.hw.vco != vco)
> > - icl_cdclk_pll_enable(dev_priv, vco);
> > - } else {
> > - if (dev_priv->cdclk.hw.vco != 0 &&
> > - dev_priv->cdclk.hw.vco != vco)
> > - bxt_de_pll_disable(dev_priv);
> > -
> > - if (dev_priv->cdclk.hw.vco != vco)
> > - bxt_de_pll_enable(dev_priv, vco);
> > - }
> > -
> > - waveform = cdclk_squash_waveform(dev_priv, cdclk);
> > -
> > - if (waveform)
> > - clock = vco / 2;
> > - else
> > - clock = cdclk;
> > -
> > - if (has_cdclk_squasher(dev_priv)) {
> > - u32 squash_ctl = 0;
> > -
> > - if (wavefor
