RE: [PATCH v4 06/19] drm/i915/xe2hpd: Add new C20 PHY SRAM address
LGTM,
Reviewed-by: Radhakrishna Sripada
> -Original Message-
> From: Intel-xe On Behalf Of
> Balasubramani Vivekanandan
> Sent: Sunday, April 21, 2024 11:40 PM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; De Marchi, Lucas
> ; Vivekanandan, Balasubramani
> ; Taylor, Clinton A
> ; Sousa, Gustavo ; Jani
> Nikula
> Subject: [PATCH v4 06/19] drm/i915/xe2hpd: Add new C20 PHY SRAM address
>
> Xe2_HPD has different offsets for C20 PHY SRAM configuration context
> location. Use the display version to select the right address.
>
> Note that Xe2_LPD uses the same C20 SRAM offsets used by Xe_LPDP (i.e.
> MTL's display). According to the BSpec, currently, only Xe2_HPD has
> different offsets, so make sure it is the only display using them in the
> driver.
>
> v2:
> * Redesigned how the right offsets are selected for different display
> IP versions.
>
> Bspec: 67610
> Cc: Clint Taylor
> Cc: Gustavo Sousa
> Cc: Jani Nikula
> Signed-off-by: Balasubramani Vivekanandan
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 65 ---
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 48 +++---
> 2 files changed, 81 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 33a612892d94..9bf882b439f4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2161,6 +2161,7 @@ static void intel_c20pll_readout_hw_state(struct
> intel_encoder *encoder,
> bool cntx;
> intel_wakeref_t wakeref;
> int i;
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>
> wakeref = intel_cx0_phy_transaction_begin(encoder);
>
> @@ -2170,42 +2171,50 @@ static void intel_c20pll_readout_hw_state(struct
> intel_encoder *encoder,
> /* Read Tx configuration */
> for (i = 0; i < ARRAY_SIZE(pll_state->tx); i++) {
> if (cntx)
> - pll_state->tx[i] = intel_c20_sram_read(encoder,
> INTEL_CX0_LANE0,
> -
> PHY_C20_B_TX_CNTX_CFG(i));
> + pll_state->tx[i] = intel_c20_sram_read(encoder,
> +
> INTEL_CX0_LANE0,
> +
> PHY_C20_B_TX_CNTX_CFG(i915, i));
> else
> - pll_state->tx[i] = intel_c20_sram_read(encoder,
> INTEL_CX0_LANE0,
> -
> PHY_C20_A_TX_CNTX_CFG(i));
> + pll_state->tx[i] = intel_c20_sram_read(encoder,
> +
> INTEL_CX0_LANE0,
> +
> PHY_C20_A_TX_CNTX_CFG(i915, i));
> }
>
> /* Read common configuration */
> for (i = 0; i < ARRAY_SIZE(pll_state->cmn); i++) {
> if (cntx)
> - pll_state->cmn[i] = intel_c20_sram_read(encoder,
> INTEL_CX0_LANE0,
> -
> PHY_C20_B_CMN_CNTX_CFG(i));
> + pll_state->cmn[i] = intel_c20_sram_read(encoder,
> +
> INTEL_CX0_LANE0,
> +
> PHY_C20_B_CMN_CNTX_CFG(i915, i));
> else
> - pll_state->cmn[i] = intel_c20_sram_read(encoder,
> INTEL_CX0_LANE0,
> -
> PHY_C20_A_CMN_CNTX_CFG(i));
> + pll_state->cmn[i] = intel_c20_sram_read(encoder,
> +
> INTEL_CX0_LANE0,
> +
> PHY_C20_A_CMN_CNTX_CFG(i915, i));
> }
>
> if (intel_c20phy_use_mpllb(pll_state)) {
> /* MPLLB configuration */
> for (i = 0; i < ARRAY_SIZE(pll_state->mpllb); i++) {
> if (cntx)
> - pll_state->mpllb[i] =
> intel_c20_sram_read(encoder, INTEL_CX0_LANE0,
> -
> PHY_C20_B_MPLLB_CNTX_CFG(i));
> + pll_state->mpllb[i] =
> intel_c20_sram_read(encoder,
> +
> INTEL_CX0_LANE0,
> +
> PHY_C20_B_MPLLB_CNTX_CFG(i915, i));
> else
> - pll_state->mpllb[i] =
> intel_c20_sram_read(encoder, INTEL_CX0_LANE0,
> -
> PHY_C20_A_MPLLB_CNTX_CFG(i));
> + pll_state->mpllb[i] =
> intel_c20_sram_read(encoder,
> +
> INTEL_CX0_LANE0,
> +
> PHY_C20_A_MPLLB_CNTX_CFG(i915, i));
> }
> } else {
> /* MPLLA configuration */
> for (i = 0; i < ARRAY_SIZE(pll_state->mplla); i++) {
> if (cntx)
> - pll_state->mplla[i] =
> intel_c20_sram_read(encoder, INTEL_CX0_LANE0,
> -
> PHY_C20_B_MPLLA_CNTX_CFG(i));
> + pll_state->mplla[i] =
> intel_c20_sram_read(encoder,
> +
> INTEL_CX0_LANE0,
> +
> PHY_C20_B_MPLLA_CNTX_CFG(i915, i));
> else
> - pll_state->mplla[i] =
> intel_c20_sram_read(encoder, INTEL_CX0_LANE0,
> -
> PHY_C20_A_MPLLA_CNTX_CFG(i));
> + pll_state->mplla[i] =
> intel_c20_sram_read(encoder,
> +
> INTEL_CX0_LANE0,
> +
> PHY_C20_A_MPLLA_CNTX_CFG(i915, i));
> }
> }
>
> @@ -2363,17 +2372,25 @@ static void
RE: [PATCH 2/2] drm/xe/display: remove compat raw reg read/write support
LGTM,
Reviewed-by: Radhakrishna Sripada
> -Original Message-
> From: Intel-xe On Behalf Of Jani
> Nikula
> Sent: Monday, April 8, 2024 5:55 AM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani ; De Marchi, Lucas
>
> Subject: [PATCH 2/2] drm/xe/display: remove compat raw reg read/write support
>
> The i915 display code no longer uses these interfaces. Remove them.
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/xe/compat-i915-headers/intel_uncore.h | 24 ---
> 1 file changed, 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
> b/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
> index ef79793caa72..a672165ececf 100644
> --- a/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
> +++ b/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
> @@ -148,28 +148,4 @@ static inline void intel_uncore_write_notrace(struct
> intel_uncore *uncore,
> xe_mmio_write32(__compat_uncore_to_gt(uncore), reg, val);
> }
>
> -static inline void __iomem *intel_uncore_regs(struct intel_uncore *uncore)
> -{
> - struct xe_device *xe = container_of(uncore, struct xe_device, uncore);
> -
> - return xe_device_get_root_tile(xe)->mmio.regs;
> -}
> -
> -/*
> - * The raw_reg_{read,write} macros are intended as a micro-optimization for
> - * interrupt handlers so that the pointer indirection on uncore->regs can
> - * be computed once (and presumably cached in a register) instead of
> generating
> - * extra load instructions for each MMIO access.
> - *
> - * Given that these macros are only intended for non-GSI interrupt registers
> - * (and the goal is to avoid extra instructions generated by the compiler),
> - * these macros do not account for uncore->gsi_offset. Any caller that needs
> - * to use these macros on a GSI register is responsible for adding the
> - * appropriate GSI offset to the 'base' parameter.
> - */
> -#define raw_reg_read(base, reg) \
> - readl(base + i915_mmio_reg_offset(reg))
> -#define raw_reg_write(base, reg, value) \
> - writel(value, base + i915_mmio_reg_offset(reg))
> -
> #endif /* __INTEL_UNCORE_H__ */
> --
> 2.39.2
RE: [PATCH 1/2] drm/i915/display: remove small micro-optimizations in irq handling
LGTM,
Reviewed-by: Radhakrishna Sripada
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Monday, April 8, 2024 5:55 AM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani ; De Marchi, Lucas
>
> Subject: [PATCH 1/2] drm/i915/display: remove small micro-optimizations in irq
> handling
>
> The raw register reads/writes are there as micro-optimizations to avoid
> multiple pointer indirections on uncore->regs. Presumably this is useful
> when there are plenty of register reads/writes in the same
> function. However, the display irq handling only has a few raw
> reads/writes. Remove them for simplification.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display_irq.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c
> b/drivers/gpu/drm/i915/display/intel_display_irq.c
> index f846c5b108b5..d4ae9139be39 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> @@ -1148,15 +1148,14 @@ void gen8_de_irq_handler(struct drm_i915_private
> *dev_priv, u32 master_ctl)
>
> u32 gen11_gu_misc_irq_ack(struct drm_i915_private *i915, const u32
> master_ctl)
> {
> - void __iomem * const regs = intel_uncore_regs(>uncore);
> u32 iir;
>
> if (!(master_ctl & GEN11_GU_MISC_IRQ))
> return 0;
>
> - iir = raw_reg_read(regs, GEN11_GU_MISC_IIR);
> + iir = intel_de_read(i915, GEN11_GU_MISC_IIR);
> if (likely(iir))
> - raw_reg_write(regs, GEN11_GU_MISC_IIR, iir);
> + intel_de_write(i915, GEN11_GU_MISC_IIR, iir);
>
> return iir;
> }
> @@ -1169,18 +1168,18 @@ void gen11_gu_misc_irq_handler(struct
> drm_i915_private *i915, const u32 iir)
>
> void gen11_display_irq_handler(struct drm_i915_private *i915)
> {
> - void __iomem * const regs = intel_uncore_regs(>uncore);
> - const u32 disp_ctl = raw_reg_read(regs, GEN11_DISPLAY_INT_CTL);
> + u32 disp_ctl;
>
> disable_rpm_wakeref_asserts(>runtime_pm);
> /*
>* GEN11_DISPLAY_INT_CTL has same format as GEN8_MASTER_IRQ
>* for the display related bits.
>*/
> - raw_reg_write(regs, GEN11_DISPLAY_INT_CTL, 0x0);
> + disp_ctl = intel_de_read(i915, GEN11_DISPLAY_INT_CTL);
> +
> + intel_de_write(i915, GEN11_DISPLAY_INT_CTL, 0);
> gen8_de_irq_handler(i915, disp_ctl);
> - raw_reg_write(regs, GEN11_DISPLAY_INT_CTL,
> - GEN11_DISPLAY_IRQ_ENABLE);
> + intel_de_write(i915, GEN11_DISPLAY_INT_CTL,
> GEN11_DISPLAY_IRQ_ENABLE);
>
> enable_rpm_wakeref_asserts(>runtime_pm);
> }
> --
> 2.39.2
RE: [PATCH v3 13/21] drm/i915/xe2hpd: Add max memory bandwidth algorithm
LGTM,
Reviewed-by: Radhakrishna Sripada
> -Original Message-
> From: Intel-xe On Behalf Of
> Balasubramani Vivekanandan
> Sent: Monday, April 15, 2024 1:14 AM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas ; Roper, Matthew D
> ; Jani Nikula ;
> Vivekanandan, Balasubramani
> Subject: [PATCH v3 13/21] drm/i915/xe2hpd: Add max memory bandwidth
> algorithm
>
> From: Matt Roper
>
> Unlike DG2, Xe2_HPD does support multiple GV points with different
> maximum memory bandwidths, but uses a much simpler algorithm than igpu
> platforms use.
>
> Bspec: 64631
> CC: Jani Nikula
> Signed-off-by: Matt Roper
> Signed-off-by: Balasubramani Vivekanandan
>
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 65 -
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/soc/intel_dram.c | 4 ++
> drivers/gpu/drm/xe/xe_device_types.h| 1 +
> 4 files changed, 69 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 7f2a50b4f494..dc9ac4831065 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -22,6 +22,8 @@ struct intel_qgv_point {
> u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
> };
>
> +#define DEPROGBWPCLIMIT 60
> +
> struct intel_psf_gv_point {
> u8 clk; /* clock in multiples of 16. MHz */
> };
> @@ -239,6 +241,9 @@ static int icl_get_qgv_points(struct drm_i915_private
> *dev_priv,
> qi->channel_width = 16;
> qi->deinterleave = 4;
> break;
> + case INTEL_DRAM_GDDR:
> + qi->channel_width = 32;
> + break;
> default:
> MISSING_CASE(dram_info->type);
> return -EINVAL;
> @@ -383,6 +388,12 @@ static const struct intel_sa_info mtl_sa_info = {
> .derating = 10,
> };
>
> +static const struct intel_sa_info xe2_hpd_sa_info = {
> + .derating = 30,
> + .deprogbwlimit = 53,
> + /* Other values not used by simplified algorithm */
> +};
> +
> static int icl_get_bw_info(struct drm_i915_private *dev_priv, const struct
> intel_sa_info *sa)
> {
> struct intel_qgv_info qi = {};
> @@ -489,7 +500,7 @@ static int tgl_get_bw_info(struct drm_i915_private
> *dev_priv, const struct intel
> dclk_max = icl_sagv_max_dclk();
>
> peakbw = num_channels * DIV_ROUND_UP(qi.channel_width, 8) *
> dclk_max;
> - maxdebw = min(sa->deprogbwlimit * 1000, peakbw * 6 / 10); /* 60% */
> + maxdebw = min(sa->deprogbwlimit * 1000, peakbw *
> DEPROGBWPCLIMIT / 100);
>
> ipqdepth = min(ipqdepthpch, sa->displayrtids / num_channels);
> /*
> @@ -594,6 +605,54 @@ static void dg2_get_bw_info(struct drm_i915_private
> *i915)
> i915->display.sagv.status = I915_SAGV_NOT_CONTROLLED;
> }
>
> +static int xe2_hpd_get_bw_info(struct drm_i915_private *i915,
> +const struct intel_sa_info *sa)
> +{
> + struct intel_qgv_info qi = {};
> + int num_channels = i915->dram_info.num_channels;
> + int peakbw, maxdebw;
> + int ret, i;
> +
> + ret = icl_get_qgv_points(i915, , true);
> + if (ret) {
> + drm_dbg_kms(>drm,
> + "Failed to get memory subsystem information,
> ignoring
> bandwidth limits");
> + return ret;
> + }
> +
> + peakbw = num_channels * qi.channel_width / 8 *
> icl_sagv_max_dclk();
> + maxdebw = min(sa->deprogbwlimit * 1000, peakbw *
> DEPROGBWPCLIMIT / 10);
> +
> + for (i = 0; i < qi.num_points; i++) {
> + const struct intel_qgv_point *point = [i];
> + int bw = num_channels * (qi.channel_width / 8) * point->dclk;
> +
> + i915->display.bw.max[0].deratedbw[i] =
> + min(maxdebw, (100 - sa->derating) * bw / 100);
> + i915->display.bw.max[0].peakbw[i] = bw;
> +
> + drm_dbg_kms(>drm, "QGV %d: deratedbw=%u peakbw:
> %u\n",
> + i, i915->display.bw.max[0].deratedbw[i],
> + i915->display.bw.max[0].peakbw[i]);
> + }
> +
> + /* Bandwidth does not depend on # of planes; set all groups the same */
> + i915->display.bw.max[0].num_planes = 1;
> + i915->display.bw.max[0].num_qgv_points = qi.num_points;
> + for (i = 1; i < ARRAY_SIZE(i915->display.bw.max); i++)
> + memcpy(>display.bw.max[i], >display.bw.max[0],
> +sizeof(i915->display.bw.max[0]));
> +
> + /*
> + * Xe2_HPD should always have exactly two QGV points representing
> + * battery and plugged-in operation.
> + */
> + drm_WARN_ON(>drm, qi.num_points != 2);
> + i915->display.sagv.status = I915_SAGV_ENABLED;
> +
> + return 0;
> +}
> +
> static unsigned int icl_max_bw_index(struct drm_i915_private
RE: ✗ Fi.CI.BAT: failure for drm/i915/xelpg: Add Wa_14020495402
The failures are not related to the changes made. Regards, Radhakrishna Sripada From: Patchwork Sent: Monday, March 18, 2024 5:15 PM To: Sripada, Radhakrishna Cc: intel-gfx@lists.freedesktop.org Subject: ✗ Fi.CI.BAT: failure for drm/i915/xelpg: Add Wa_14020495402 Patch Details Series: drm/i915/xelpg: Add Wa_14020495402 URL: https://patchwork.freedesktop.org/series/131291/ State: failure Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/index.html CI Bug Log - changes from CI_DRM_14443 -> Patchwork_131291v1 Summary FAILURE Serious unknown changes coming with Patchwork_131291v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_131291v1, please notify your bug team (i915-ci-in...@lists.freedesktop.org<mailto:i915-ci-in...@lists.freedesktop.org>) 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_131291v1/index.html Participating hosts (35 -> 33) Additional (2): bat-arls-4 bat-jsl-1 Missing (4): bat-kbl-2 bat-dg2-11 fi-snb-2520m fi-kbl-8809g Possible new issues Here are the unknown changes that may have been introduced in Patchwork_131291v1: IGT changes Possible regressions * igt@i915_pm_rpm@module-reload: * bat-arls-1: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14443/bat-arls-1/igt@i915_pm_...@module-reload.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/bat-arls-1/igt@i915_pm_...@module-reload.html> * igt@i915_selftest@live@hangcheck: * bat-adlm-1: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14443/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html> -> INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/bat-adlm-1/igt@i915_selftest@l...@hangcheck.html> Known issues Here are the changes found in Patchwork_131291v1 that come from known issues: CI changes Possible fixes * boot: * fi-cfl-8109u: FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14443/fi-cfl-8109u/boot.html> (i915#8293<https://gitlab.freedesktop.org/drm/intel/issues/8293>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/fi-cfl-8109u/boot.html> IGT changes Issues hit * igt@debugfs_test@basic-hwmon: * bat-jsl-1: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html> (i915#9318<https://gitlab.freedesktop.org/drm/intel/issues/9318>) * igt@gem_huc_copy@huc-copy: * fi-cfl-8109u: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html> (i915#2190<https://gitlab.freedesktop.org/drm/intel/issues/2190>) * bat-jsl-1: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html> (i915#2190<https://gitlab.freedesktop.org/drm/intel/issues/2190>) * igt@gem_lmem_swapping@verify-random: * fi-cfl-8109u: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html> (i915#4613<https://gitlab.freedesktop.org/drm/intel/issues/4613>) +3 other tests skip * bat-jsl-1: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/bat-jsl-1/igt@gem_lmem_swapp...@verify-random.html> (i915#4613<https://gitlab.freedesktop.org/drm/intel/issues/4613>) +3 other tests skip * igt@i915_selftest@live@hugepages: * fi-apl-guc: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14443/fi-apl-guc/igt@i915_selftest@l...@hugepages.html> -> ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/fi-apl-guc/igt@i915_selftest@l...@hugepages.html> (i915#10461<https://gitlab.freedesktop.org/drm/intel/issues/10461>) * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: * bat-jsl-1: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/bat-jsl-1/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html> (i915#4103<https://gitlab.freedesktop.org/drm/intel/issues/4103>) +1 other test skip * igt@kms_dsc@dsc-basic: * bat-jsl-1: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/bat-jsl-1/igt@kms_...@dsc-basic.html> (i915#3555<https://gitlab.freedesktop.org/drm/intel/issues/3555> / i915#9886<https://gitlab.freedesktop.org/drm/intel/issues/9886>) * igt@kms_force_connector_basic@force-load-detect: * bat-jsl-1: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_131291v1/bat-jsl-1/igt@kms_force_connector_ba...@force-load-detect.html> * igt@kms_pm_backlight@bas
RE: [PATCH] drm/i915/opregion: add intel_opregion_vbt_present() stub for ACPI=n
LGTM,
Reviewed-by: Radhakrishna Sripada
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, March 12, 2024 4:58 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Thomas Weißschuh
> ; Sripada, Radhakrishna
>
> Subject: [PATCH] drm/i915/opregion: add intel_opregion_vbt_present() stub for
> ACPI=n
>
> The opregion code needs stubs for ACPI=n. Add the missing stub for
> intel_opregion_vbt_present().
>
> Reported-by: Thomas Weißschuh
> Closes: https://lore.kernel.org/r/20240312120240-afdb1b83-8517-434b-be79-
> 06f41bafd...@linutronix.de
> Fixes: 9d9bb71f3e11 ("drm/i915: Extract opregion vbt presence check")
> Cc: Radhakrishna Sripada
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_opregion.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.h
> b/drivers/gpu/drm/i915/display/intel_opregion.h
> index 63573c38d735..4b2b8e752632 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.h
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.h
> @@ -120,6 +120,11 @@ intel_opregion_get_edid(struct intel_connector
> *connector)
> return NULL;
> }
>
> +static inline bool intel_opregion_vbt_present(struct drm_i915_private *i915)
> +{
> + return false;
> +}
> +
> static inline const void *
> intel_opregion_get_vbt(struct drm_i915_private *i915, size_t *size)
> {
> --
> 2.39.2
RE: [PATCH v2] drm/i915: Reuse RPLU cdclk fns for MTL+
Merged the patch. Thanks for the reviews.
Regards,
Radhakrishna Sripada
> -Original Message-
> From: Sripada, Radhakrishna
> Sent: Wednesday, February 28, 2024 1:49 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sripada, Radhakrishna ; Sousa, Gustavo
> ; Nikula, Jani
> Subject: [PATCH v2] drm/i915: Reuse RPLU cdclk fns for MTL+
>
> MTL/LNL use the same cdclk functions as RPLU albeit with different
> tables. Having separate tables and not requiring special handling
> for the platforms, reuse RPLU cdclk functions.
>
> v2: Update subject and the commit message(Jani)
>
> Cc: Gustavo Sousa
> Reviewed-by: Jani Nikula
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 22473c55b899..5b2688d8c644 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -3559,13 +3559,6 @@ void intel_cdclk_debugfs_register(struct
> drm_i915_private *i915)
> i915, _cdclk_info_fops);
> }
>
> -static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
> - .get_cdclk = bxt_get_cdclk,
> - .set_cdclk = bxt_set_cdclk,
> - .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
> - .calc_voltage_level = rplu_calc_voltage_level,
> -};
> -
> static const struct intel_cdclk_funcs rplu_cdclk_funcs = {
> .get_cdclk = bxt_get_cdclk,
> .set_cdclk = bxt_set_cdclk,
> @@ -3709,10 +3702,10 @@ static const struct intel_cdclk_funcs
> i830_cdclk_funcs = {
> void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
> {
> if (DISPLAY_VER(dev_priv) >= 20) {
> - dev_priv->display.funcs.cdclk = _cdclk_funcs;
> + dev_priv->display.funcs.cdclk = _cdclk_funcs;
> dev_priv->display.cdclk.table = lnl_cdclk_table;
> } else if (DISPLAY_VER(dev_priv) >= 14) {
> - dev_priv->display.funcs.cdclk = _cdclk_funcs;
> + dev_priv->display.funcs.cdclk = _cdclk_funcs;
> dev_priv->display.cdclk.table = mtl_cdclk_table;
> } else if (IS_DG2(dev_priv)) {
> dev_priv->display.funcs.cdclk = _cdclk_funcs;
> --
> 2.34.1
RE: [RFC 00/15] VBT read Cleanup
Hi Jani, > -Original Message- > From: Jani Nikula > Sent: Wednesday, January 10, 2024 4:34 AM > To: Sripada, Radhakrishna ; intel- > g...@lists.freedesktop.org > Subject: Re: [RFC 00/15] VBT read Cleanup > > On Mon, 08 Jan 2024, Radhakrishna Sripada > wrote: > > This series does the VBT read cleanup. The series introduces new > > intel_vbt structure to cache and collate vbt related info. Vbt > > read from different sources viz. firmware/opregion/spi/oprom > > needs to be cached for debug purposes and handled accordingly > > during cleanup. > > Mixed feelings. I think the goal is good, not convinced by the > implementation. > > First, i915->display.vbt.data.foo is just too much depth. It was > borderline too much before, but now it definitely is. Sure. I will cache and store the parsed fields under the same structure. > > Second, whichever place allocates some stuff should also be responsible > for freeing it. I don't like the idea that you have different places > allocating and then you have a combined cleanup to take care of the > alternatives. Previously, allocations were happening under spi_get_oprom_vbt and oprom_get_vbt but the de-allocation was happening immediately in intel_bios_init. Because we need to cache vbt we will have to free the memory only during driver remove phase. I understand what you are suggesting here, the problem that I was thinking is how to determine the sizes without extra reads, your series does it in a clean way. Will use that way to peek into the presence of vbt's in spi and oprom. > > Possibly the first thing to do would be to put intel_bios_init() in > charge of picking the VBT. Stop looking at opregion directly in > intel_bios.c, and instead abstract that away. Also move firmware EDID > loading there. Move debugfs there. Etc. I think you meant firmware vbt here. I will rebase my work on top of your work of opregion cleanup and come with a new series. Thanks, Radhakrishna(RK) Sripada > > The opregion code could still figure out what its idea of VBT is, but > intel_bios_init() would the place to ask opregion code about it only if > needed. > > > BR, > Jani. > > > > > > > > > Radhakrishna Sripada (15): > > drm/i915: Extract display->vbt_data to a new vbt structure > > drm/i915: Move vbt fields from opregion to its own structure > > drm/i915: Cache opregion asls pointer > > drm/i915: Extract opregion vbt capture to its own function > > drm/i915: Init vbt fields when read from oprom/spi > > drm/i915: Classify vbt type based on its residence > > drm/i915: Collate vbt cleanup for different types > > drm/i915: Make intel_bios_init operate on intel_vbt > > drm/i915: Move vbt load from opregion to bios init > > drm/i915: Move vbt firmware load into intel_bios_init > > drm/i915: Make oprom_get_vbt operate on intel_vbt > > drm/i915: Make spi_oprom_get_vbt operate on intel_vbt > > drm/i915: Make intel_load_vbt_firmware operate on intel_vbt > > drm/i915: Kill reduntant vbt_firmware from intel_vbt > > drm/i915: Use vbt type to determine its validity > > > > drivers/gpu/drm/i915/display/intel_bios.c | 348 +++--- > > drivers/gpu/drm/i915/display/intel_crt.c | 2 +- > > drivers/gpu/drm/i915/display/intel_display.c | 10 +- > > .../gpu/drm/i915/display/intel_display_core.h | 16 +- > > .../drm/i915/display/intel_display_debugfs.c | 6 +- > > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > > drivers/gpu/drm/i915/display/intel_dpll.c | 16 +- > > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 19 +- > > drivers/gpu/drm/i915/display/intel_dsi.c | 2 +- > > drivers/gpu/drm/i915/display/intel_lvds.c | 4 +- > > drivers/gpu/drm/i915/display/intel_opregion.c | 165 - > > drivers/gpu/drm/i915/display/intel_opregion.h | 13 +- > > drivers/gpu/drm/i915/display/intel_panel.c| 2 +- > > .../gpu/drm/i915/display/intel_pch_refclk.c | 2 +- > > drivers/gpu/drm/i915/display/intel_sdvo.c | 18 +- > > drivers/gpu/drm/i915/intel_clock_gating.c | 2 +- > > 16 files changed, 348 insertions(+), 279 deletions(-) > > -- > Jani Nikula, Intel
RE: [PATCH v2 0/4] TC phy check cleanup
Hi Jani, Thank you for that insight. I will use it for future reference. And as in this case the 1%wart looks better. Need to evaluate if having a tc_phy_mask(as pointed by Imre) in platform info will make things pretty in this case. Regards, Radhakrishna(RK) Sripada > -Original Message- > From: Jani Nikula > Sent: Friday, December 22, 2023 2:04 AM > To: Sripada, Radhakrishna ; intel- > g...@lists.freedesktop.org > Subject: RE: [PATCH v2 0/4] TC phy check cleanup > > On Fri, 22 Dec 2023, "Sripada, Radhakrishna" > wrote: > > Hi Jani, > > > >> -Original Message- > >> From: Jani Nikula > >> Sent: Thursday, December 21, 2023 2:04 AM > >> To: Sripada, Radhakrishna ; intel- > >> g...@lists.freedesktop.org > >> Subject: Re: [PATCH v2 0/4] TC phy check cleanup > >> > >> On Wed, 20 Dec 2023, Radhakrishna Sripada > > >> wrote: > >> > We are relying on end-less if-else ladders for a type-c phy > >> > capabilities check. Though it made sense when platforms supported > >> > legacy type-c support, modern platforms rely on the information > >> > passed by vbt. This cleanup restricts the if-else ladder to the > >> > platforms supporting legacy type-c phys and relies on vbt info > >> > for modern client and discrete platforms. > >> > >> This series is moving the vbt handling in the wrong direction. > >> > >> We want to *avoid* new lookups. The idea is that you do the lookup > >> *once* when initializing the encoder, and after that you use > >> encoder->devdata. > >> > >> If you look at the intel_phy_is_tc() call sites, you'll observe that > >> almost all of the places have the encoder (or devdata) already > >> available. They get the port from encoder->port, and the phy from > >> intel_port_to_phy(). > >> > >> So this throws away the information that's already available, and then > >> goes to look it up again in the worst possible way. > >> > >> You should convert intel_phy_is_tc() to something like > >> intel_encoder_is_tc(), and pass encoder to it instead of phy. Similarly, > >> intel_port_to_tc() should be converted to intel_encoder_to_tc(). > >> > >> There are a couple of special cases that only have devdata or phy. But > >> we can handle the special cases after making the common case > >> straightforward. > > Common case making a tc check out of encoder sure makes lot of sense > > And agreed to you point. The question that arises in the special cases. > > For ex. during vbt_defaults init in intel_bios.c, I can only handle for > > legacy tc > ports. > > > > In other cases where only phy info is available, I may have to iterate over > > all the > > drm_encoders to obtain port info and compare it with phy info adding lot of > lookup > > overhead. Or we may have to use encoder based lookups in all associated > lookups like > > icl_port_to_ddc_pin etc. > > > > Thoughts? > > Frankly, the way I often handle stuff like this is just start making the > changes for the things that obviously make sense. Such as looking the tc > info up via the encoder. You can add the new function(s) and gradually > switch over. It's mostly mechanical changes and pretty quick to do. I > think it'll even clean up a bunch of local enum port and enum phy > usages. > > And often the answer to the rest just presents itself. > > Sometimes the answer is, well, to leave an ugly wart in 1% of the cases > while making 99% of the cases pretty. And that's still better than > having 100% poor design. > > Sometimes you find out you have to redo some of the stuff you did at > first, but it's because you figure things out along the way. For me at > least, this is how the bright ideas come to mind more often than via up > front design attempts. > > HTH, > Jani. > > > > > > Radhakrishna(RK) Sripada > >> > >> > >> BR, > >> Jani. > >> > >> > >> > > >> > v2: Move cleanup vbt later to handle safe encoder removal > >> > > >> > Radhakrishna Sripada (4): > >> > drm/i915: Move intel_bios_driver_remove later > >> > drm/i915: Rename intel_bios_encoder_data_lookup as a port variant > >> > drm/i915: Introduce intel_encoder_phy_data_lookup > >> > drm/i915: Separate tc check for legacy and non legacy tc phys > >> > > >> > drivers/gpu/drm/i915/display/g4x_dp.c | 2 +- > >> > drivers/gpu/drm/i915/display/g4x_hdmi.c | 2 +- > >> > drivers/gpu/drm/i915/display/intel_bios.c | 15 +- > >> > drivers/gpu/drm/i915/display/intel_bios.h | 5 +++- > >> > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > >> > drivers/gpu/drm/i915/display/intel_display.c | 29 --- > >> > .../drm/i915/display/intel_display_device.h | 1 + > >> > .../drm/i915/display/intel_display_driver.c | 4 +-- > >> > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > >> > 9 files changed, 44 insertions(+), 18 deletions(-) > >> > >> -- > >> Jani Nikula, Intel > > -- > Jani Nikula, Intel
RE: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non legacy tc phys
Hi Imre,
Thank you for the pointer. Let me evaluate and see if it is worth taking that
trouble.
Thanks,
Radhakrishna(RK) Sripada
> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, January 3, 2024 8:51 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non
> legacy tc phys
>
> On Fri, Dec 22, 2023 at 09:47:49PM +0200, Sripada, Radhakrishna wrote:
> > Hi Imre,
> >
> > I have question related to tc legacy handling. I am looking in the context
> > of
> discrete cards.
> >
> > > -Original Message-
> > > From: Deak, Imre
> > > Sent: Friday, December 22, 2023 3:44 AM
> > > To: Sripada, Radhakrishna
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Subject: Re: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non
> > > legacy tc phys
> > >
> > > On Wed, Dec 20, 2023 at 02:13:41PM -0800, Radhakrishna Sripada wrote:
> > > > Starting MTL and DG2 if a phy is not marked as USB-typeC or TBT capable
> > > > by vbt we should not consider it as a Legacy type-c phy.
> > > >
> > > > The concept of Legacy-tc existed in platforms from Icelake to Alder lake
> > > > where an external FIA can be routed to one of the phy's thus making the
> > > > phy
> > > > tc capable without being marked in the vbt.
> > > >
> > > > Discrete cards have native ports and client products post MTL have a 1:1
> > > > mapping with type-C subsystem which is advertised by the bios. So rely
> > > > on
> > > > the vbt info regarding type-c capability.
> > > >
> > > > Signed-off-by: Radhakrishna Sripada
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> > > > drivers/gpu/drm/i915/display/intel_display.c | 29 ---
> > > > .../drm/i915/display/intel_display_device.h | 1 +
> > > > 3 files changed, 21 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > index 12a29363e5df..7d5b95f97d5f 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > @@ -5100,7 +5100,7 @@ void intel_ddi_init(struct drm_i915_private
> > > *dev_priv,
> > > > }
> > > >
> > > > if (intel_phy_is_tc(dev_priv, phy)) {
> > > > - bool is_legacy =
> > > > + bool is_legacy = HAS_LEGACY_TC(dev_priv) &&
> > >
> > > This doesn't make sense to me. PHYs are either TC or non-TC (aka combo
> > > PHY) and TC PHYs can be configured to work either in legacy (a TC PHY
> > > wired to a native DP connector) or non-legacy mode (a TC PHY wired to a
> > > TC connector). So this would break the functionality on MTL native DP
> > > connectors and all future platforms I looked at which also support this.
> >
> >
> > I understand. I want to figure out a way to determine if a phy is
> > connected to FIA. Like in DG2, the phy's are not connected to FIA. I
> > am assuming that will be the case for all future discrete cards as
> > well. So instead of looking/building an if-else ladder for the phy
> > check, is there something that we can rely on viz. vbt, register etc.
> > to determine if FIA is connected to a phy?
>
> I suppose this question is if a PHY is TypeC or not, TypeC requiring
> some kind of mux (which can be FIA or something else). One other way
> instead of the if-ladder in intel_phy_is_tc() would be adding a
> tc_phy_mask to intel_display_runtime_info, similarly to the port_mask
> there. Not sure how much that would improve things over the current way.
>
> > > > !intel_bios_encoder_supports_typec_usb(devdata) &&
> > > > !intel_bios_encoder_supports_tbt(devdata);
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index b10aad15a63d..03006c9af824 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -1854,17 +1854,9 @@ bool intel_phy_is_combo(struct
> drm_i915_private
> > > *dev_priv, enum phy phy)
> > > > return false;
> > > >
RE: [PATCH] drm/i915/display: Skip C10 state verification in case of fastset
> -Original Message-
> From: Intel-gfx On Behalf Of Mika
> Kahola
> Sent: Tuesday, December 19, 2023 4:33 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/i915/display: Skip C10 state verification in case of
> fastset
>
> PLL's are not programmed in case of fastset so the state
> verfication compares bios programmed PLL values against
> sw PLL values. To overcome this limitation, we can skip
> the state verification for C10 in fastset case as the
> driver is not writing PLL values.
>
LGTM,
Reviewed-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 884a1da36089..3ef54eaca9e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -3016,6 +3016,9 @@ static void intel_c10pll_state_verify(const struct
> intel_crtc_state *state,
> const struct intel_c10pll_state *mpllb_sw_state =
> >cx0pll_state.c10;
> int i;
>
> + if (intel_crtc_needs_fastset(state))
> + return;
> +
> for (i = 0; i < ARRAY_SIZE(mpllb_sw_state->pll); i++) {
> u8 expected = mpllb_sw_state->pll[i];
>
> --
> 2.34.1
RE: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non legacy tc phys
Hi Imre,
I have question related to tc legacy handling. I am looking in the context of
discrete cards.
> -Original Message-
> From: Deak, Imre
> Sent: Friday, December 22, 2023 3:44 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2 4/4] drm/i915: Separate tc check for legacy and non
> legacy tc phys
>
> On Wed, Dec 20, 2023 at 02:13:41PM -0800, Radhakrishna Sripada wrote:
> > Starting MTL and DG2 if a phy is not marked as USB-typeC or TBT capable
> > by vbt we should not consider it as a Legacy type-c phy.
> >
> > The concept of Legacy-tc existed in platforms from Icelake to Alder lake
> > where an external FIA can be routed to one of the phy's thus making the phy
> > tc capable without being marked in the vbt.
> >
> > Discrete cards have native ports and client products post MTL have a 1:1
> > mapping with type-C subsystem which is advertised by the bios. So rely on
> > the vbt info regarding type-c capability.
> >
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 29 ---
> > .../drm/i915/display/intel_display_device.h | 1 +
> > 3 files changed, 21 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 12a29363e5df..7d5b95f97d5f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -5100,7 +5100,7 @@ void intel_ddi_init(struct drm_i915_private
> *dev_priv,
> > }
> >
> > if (intel_phy_is_tc(dev_priv, phy)) {
> > - bool is_legacy =
> > + bool is_legacy = HAS_LEGACY_TC(dev_priv) &&
>
> This doesn't make sense to me. PHYs are either TC or non-TC (aka combo
> PHY) and TC PHYs can be configured to work either in legacy (a TC PHY
> wired to a native DP connector) or non-legacy mode (a TC PHY wired to a
> TC connector). So this would break the functionality on MTL native DP
> connectors and all future platforms I looked at which also support this.
I understand. I want to figure out a way to determine if a phy is connected to
FIA. Like in DG2, the phy's are not connected to FIA. I am assuming that will be
the case for all future discrete cards as well. So instead of looking/building
an
if-else ladder for the phy check, is there something that we can rely on viz.
vbt, register etc.
to determine if FIA is connected to a phy?
>
> > !intel_bios_encoder_supports_typec_usb(devdata) &&
> > !intel_bios_encoder_supports_tbt(devdata);
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> > index b10aad15a63d..03006c9af824 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1854,17 +1854,9 @@ bool intel_phy_is_combo(struct drm_i915_private
> *dev_priv, enum phy phy)
> > return false;
> > }
> >
> > -bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> > +static bool intel_phy_is_legacy_tc(struct drm_i915_private *dev_priv, enum
> phy phy)
> > {
> > - /*
> > -* DG2's "TC1", although TC-capable output, doesn't share the same flow
> > -* as other platforms on the display engine side and rather rely on the
> > -* SNPS PHY, that is programmed separately
> > -*/
> > - if (IS_DG2(dev_priv))
> > - return false;
> > -
> > - if (DISPLAY_VER(dev_priv) >= 13)
> > + if (DISPLAY_VER(dev_priv) == 13)
> > return phy >= PHY_F && phy <= PHY_I;
> > else if (IS_TIGERLAKE(dev_priv))
> > return phy >= PHY_D && phy <= PHY_I;
> > @@ -1874,6 +1866,23 @@ bool intel_phy_is_tc(struct drm_i915_private
> *dev_priv, enum phy phy)
> > return false;
> > }
> >
> > +static bool intel_phy_is_vbt_tc(struct drm_i915_private *dev_priv, enum phy
> phy)
> > +{
> > + const struct intel_bios_encoder_data *data =
> > + intel_bios_encoder_phy_data_lookup(dev_priv, phy);
> > +
> > + return intel_bios_encoder_supports_typec_usb(data) &&
> > + intel_bios_encoder_supports_tbt(data);
>
> Based on the above, this doesn't look correct: a TC PHY can be
> configured by the vendor (reflected by the above typec_usb and tbt flags
> in VBT) in any of the following ways:
>
> -
RE: [PATCH v2 0/4] TC phy check cleanup
Hi Jani, > -Original Message- > From: Jani Nikula > Sent: Thursday, December 21, 2023 2:04 AM > To: Sripada, Radhakrishna ; intel- > g...@lists.freedesktop.org > Subject: Re: [PATCH v2 0/4] TC phy check cleanup > > On Wed, 20 Dec 2023, Radhakrishna Sripada > wrote: > > We are relying on end-less if-else ladders for a type-c phy > > capabilities check. Though it made sense when platforms supported > > legacy type-c support, modern platforms rely on the information > > passed by vbt. This cleanup restricts the if-else ladder to the > > platforms supporting legacy type-c phys and relies on vbt info > > for modern client and discrete platforms. > > This series is moving the vbt handling in the wrong direction. > > We want to *avoid* new lookups. The idea is that you do the lookup > *once* when initializing the encoder, and after that you use > encoder->devdata. > > If you look at the intel_phy_is_tc() call sites, you'll observe that > almost all of the places have the encoder (or devdata) already > available. They get the port from encoder->port, and the phy from > intel_port_to_phy(). > > So this throws away the information that's already available, and then > goes to look it up again in the worst possible way. > > You should convert intel_phy_is_tc() to something like > intel_encoder_is_tc(), and pass encoder to it instead of phy. Similarly, > intel_port_to_tc() should be converted to intel_encoder_to_tc(). > > There are a couple of special cases that only have devdata or phy. But > we can handle the special cases after making the common case > straightforward. Common case making a tc check out of encoder sure makes lot of sense And agreed to you point. The question that arises in the special cases. For ex. during vbt_defaults init in intel_bios.c, I can only handle for legacy tc ports. In other cases where only phy info is available, I may have to iterate over all the drm_encoders to obtain port info and compare it with phy info adding lot of lookup overhead. Or we may have to use encoder based lookups in all associated lookups like icl_port_to_ddc_pin etc. Thoughts? Radhakrishna(RK) Sripada > > > BR, > Jani. > > > > > > v2: Move cleanup vbt later to handle safe encoder removal > > > > Radhakrishna Sripada (4): > > drm/i915: Move intel_bios_driver_remove later > > drm/i915: Rename intel_bios_encoder_data_lookup as a port variant > > drm/i915: Introduce intel_encoder_phy_data_lookup > > drm/i915: Separate tc check for legacy and non legacy tc phys > > > > drivers/gpu/drm/i915/display/g4x_dp.c | 2 +- > > drivers/gpu/drm/i915/display/g4x_hdmi.c | 2 +- > > drivers/gpu/drm/i915/display/intel_bios.c | 15 +- > > drivers/gpu/drm/i915/display/intel_bios.h | 5 +++- > > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > > drivers/gpu/drm/i915/display/intel_display.c | 29 --- > > .../drm/i915/display/intel_display_device.h | 1 + > > .../drm/i915/display/intel_display_driver.c | 4 +-- > > drivers/gpu/drm/i915/display/intel_dp.c | 2 +- > > 9 files changed, 44 insertions(+), 18 deletions(-) > > -- > Jani Nikula, Intel
RE: [PATCH] drm/i915: Piggyback opregion vbt to store vbt read from flash/oprom
Hi Jani,
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, December 20, 2023 1:38 AM
> To: Ville Syrjälä ; Sripada, Radhakrishna
>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915: Piggyback opregion vbt to store vbt read from
> flash/oprom
>
> On Wed, 20 Dec 2023, Ville Syrjälä wrote:
> > On Tue, Dec 19, 2023 at 05:49:52PM -0800, Radhakrishna Sripada wrote:
> >> Discrete cards do not have ACPI opregion. The vbt is stored in a special
> >> flash accessible by the display controller. In order to access the vbt
> >> in such cases, re-use the vbt, vbt_size fields in the opregion structure.
> >
> > Why?
>
> The i915_vbt debugfs file probably does not work for VBT from SPI
> flash. We should fix that.
>
> But this patch is not the way to go. If the VBT does not come from
> opregion, it shouldn't be stored in the opregion structures. Maybe this
> needs another abstraction layer. *grin*.
>
> Specifically, one of the problems here is that the allocation and free
> of the VBT originating from SPI flash happens at completely different
> modules and abstraction layers. That's usually a recipe for disaster
> later.
I fully agree with you. I have thus made the statement in the original commit
that we would need to move away from storing vbt in opregion. I will try to
come up with a new patchset the stores vbt in the vbt structure itself and not
in
the opregion.
Thanks,
Radhakrishan(RK) Sripada
>
>
> BR,
> Jani.
>
>
> >
> >>
> >> We should move away from storing the vbt in the opregion and store it,
> >> if required in the vbt structure.
> >>
> >> Signed-off-by: Radhakrishna Sripada
> >> ---
> >> drivers/gpu/drm/i915/display/intel_bios.c | 44 ++-
> >> drivers/gpu/drm/i915/display/intel_opregion.c | 7 ++-
> >> 2 files changed, 29 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> >> index 736499a6e2c7..cbfbc56ff5b2 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> >> @@ -2930,12 +2930,11 @@ static u32 intel_spi_read(struct intel_uncore
> *uncore, u32 offset)
> >>return intel_uncore_read(uncore, PRIMARY_SPI_TRIGGER);
> >> }
> >>
> >> -static struct vbt_header *spi_oprom_get_vbt(struct drm_i915_private *i915)
> >> +static struct vbt_header *spi_oprom_get_vbt(struct drm_i915_private *i915,
> u16 *vbt_size)
> >> {
> >>u32 count, data, found, store = 0;
> >>u32 static_region, oprom_offset;
> >>u32 oprom_size = 0x20;
> >> - u16 vbt_size;
> >>u32 *vbt;
> >>
> >>static_region = intel_uncore_read(>uncore, SPI_STATIC_REGIONS);
> >> @@ -2957,18 +2956,18 @@ static struct vbt_header
> *spi_oprom_get_vbt(struct drm_i915_private *i915)
> >>goto err_not_found;
> >>
> >>/* Get VBT size and allocate space for the VBT */
> >> - vbt_size = intel_spi_read(>uncore,
> >> + *vbt_size = intel_spi_read(>uncore,
> >> found + offsetof(struct vbt_header,
> >> vbt_size));
> >> - vbt_size &= 0x;
> >> + *vbt_size &= 0x;
> >>
> >> - vbt = kzalloc(round_up(vbt_size, 4), GFP_KERNEL);
> >> + vbt = kzalloc(round_up(*vbt_size, 4), GFP_KERNEL);
> >>if (!vbt)
> >>goto err_not_found;
> >>
> >> - for (count = 0; count < vbt_size; count += 4)
> >> + for (count = 0; count < *vbt_size; count += 4)
> >>*(vbt + store++) = intel_spi_read(>uncore, found + count);
> >>
> >> - if (!intel_bios_is_valid_vbt(vbt, vbt_size))
> >> + if (!intel_bios_is_valid_vbt(vbt, *vbt_size))
> >>goto err_free_vbt;
> >>
> >>drm_dbg_kms(>drm, "Found valid VBT in SPI flash\n");
> >> @@ -2977,16 +2976,16 @@ static struct vbt_header
> *spi_oprom_get_vbt(struct drm_i915_private *i915)
> >>
> >> err_free_vbt:
> >>kfree(vbt);
> >> + *vbt_size = 0;
> >> err_not_found:
> >>return NULL;
> >> }
> >>
> >> -static struct vbt_header *oprom_get_vbt(struct drm_i915_private *i915)
> >> +static struct vbt_header *oprom_get_vbt(struct drm_i915_private *i915, u16
> *vbt_size)
> >> {
> >>struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> >>
RE: [PATCH v2 04/15] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access
> -Original Message-
> From: Ville Syrjala
> Sent: Friday, December 15, 2023 2:59 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Paz Zcharya ; Das, Nirmoy ;
> Sripada, Radhakrishna ; Joonas Lahtinen
>
> Subject: [PATCH v2 04/15] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL
> stolen memory access
>
> From: Ville Syrjälä
>
> On MTL accessing stolen memory via the BARs is somehow borked,
> and it can hang the machine. As a workaround let's bypass the
> BARs and just go straight to DSMBASE/GSMBASE instead.
>
> Note that on every other platform this itself would hang the
> machine, but on MTL the system firmware is expected to relax
> the access permission guarding stolen memory to enable this
> workaround, and thus direct CPU accesses should be fine.
>
> TODO: add w/a numbers and whatnot
Wa_22018444074 is more appropriate here.
With that,
Reviewed-by: Radhakrishna Sripada
>
> Cc: Paz Zcharya
> Cc: Nirmoy Das
> Cc: Radhakrishna Sripada
> Cc: Joonas Lahtinen
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 11 ++-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 13 -
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index ee237043c302..252fe5cd6ede 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -941,7 +941,16 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private
> *i915, u16 type,
> dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M);
> }
>
> - if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
> + if (IS_METEORLAKE(i915)) {
> + /*
> + * Workaround: access via BAR can hang MTL, go directly to
> DSM.
> + *
> + * Normally this would not work but on MTL the system
> firmware
> + * should have relaxed the access permissions sufficiently.
> + */
> + io_start = intel_uncore_read64(uncore, GEN12_DSMBASE) &
> GEN12_BDSM_MASK;
> + io_size = dsm_size;
> + } else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
> io_start = 0;
> io_size = 0;
> } else {
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 21a7e3191c18..ab71d74ec426 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -24,6 +24,7 @@
> #include "intel_ring.h"
> #include "i915_drv.h"
> #include "i915_pci.h"
> +#include "i915_reg.h"
> #include "i915_request.h"
> #include "i915_scatterlist.h"
> #include "i915_utils.h"
> @@ -1152,13 +1153,23 @@ static unsigned int gen6_gttadr_offset(struct
> drm_i915_private *i915)
> static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
> {
> struct drm_i915_private *i915 = ggtt->vm.i915;
> + struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> phys_addr_t phys_addr;
> u32 pte_flags;
> int ret;
>
> GEM_WARN_ON(pci_resource_len(pdev, GEN4_GTTMMADR_BAR) !=
> gen6_gttmmadr_size(i915));
> - phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) +
> gen6_gttadr_offset(i915);
> + /*
> + * Workaround: access via BAR can hang MTL, go directly to GSM.
> + *
> + * Normally this would not work but on MTL the system firmware
> + * should have relaxed the access permissions sufficiently.
> + */
> + if (IS_METEORLAKE(i915))
> + phys_addr = intel_uncore_read64(uncore, GEN12_GSMBASE) &
> GEN12_BDSM_MASK;
> + else
> + phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR)
> + gen6_gttadr_offset(i915);
>
> if (needs_wc_ggtt_mapping(i915))
> ggtt->gsm = ioremap_wc(phys_addr, size);
> --
> 2.41.0
RE: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access
HI Ville, > -Original Message- > From: Ville Syrjälä > Sent: Wednesday, December 13, 2023 6:03 PM > To: Sripada, Radhakrishna > Cc: Joonas Lahtinen ; Das, Nirmoy > ; intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL > stolen memory access > > On Wed, Dec 13, 2023 at 08:18:15PM +, Sripada, Radhakrishna wrote: > > Hi Ville, > > > > +Nirmoy > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Wednesday, December 13, 2023 1:30 AM > > > To: Joonas Lahtinen > > > Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna > > > > > > Subject: Re: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL > > > stolen memory access > > > > > > On Wed, Dec 13, 2023 at 11:09:38AM +0200, Joonas Lahtinen wrote: > > > > Quoting Ville Syrjala (2023-12-13 02:42:29) > > > > > From: Ville Syrjälä > > > > > > > > > > On MTL accessing stolen memory via the BARs is somehow borked, > > > > > and it can hang the machine. As a workaround let's bypass the > > > > > BARs and just go straight to DSMBASE/GSMBASE instead. > > > > > > > > > > Note that on every other platform this itself would hang the > > > > > machine, but on MTL the system firmware is expected to relax > > > > > the access permission guarding stolen memory to enable this > > > > > workaround, and thus direct CPU accesses should be fine. > > > > > > > > Shouldn't this have a proper workaround number assigned? > > > > > > I think there are various numbers, half of which I couldn't even > > > find in any database, and the other half I couldn't access for > > > whatever reason. So dunno what situation really is apart from > > > the firmware clearly implemening its part (since I can poke > > > DSM/GSM directly without killing the machine). > > > > > > RK do you know what we should call this? > > Nirmoy previously used Wa_22018444074 in [1]. > > > > There were some associated issues Wa_13010847436 and Wa_14019519902 > > which Nirmoy quoted in [2]. > > > > Wa_22018529850 is derived from Wa_22018444074, is targeting the latest Gop > > driver change which is installed in bat-mtlp-8 hopefully it should help > > debug the > issue further. > > > > > > Regarding the patch itself, > > Do we need to carve out the range from e820 the area around DSM if we can > directly access the range from CPU > > without the bar? > > IIRC we dropped the early quirks on new platforms under the > assumption that the BIOS no longer forgets to mark the DSM > as not-RAM/whatever. I don't think anything should change > there even when we are allowed direct CPU access. > > But I don't recall if I double checked the e820 listing on > the MTL I was using. I was able to direct access to both DSM > and GSM for sure, and the address the GOP handed over to efifb > also pointed directly to DSM. Up until adl-p/rpl, the PCI config space had the mirror registers for the stolen memory base and size, since the stolen meory is carved out of the available physical ram. Starting MTL this was removed from pci config space due to the introduction of stolen lmem which should not be cpu addressable aperture. With the new gop driver allocating the FB memory in dram, should the e820 mark the FB area as reserved for the system use? Do we still preserve the efifb after doing a memtest before loading the driver? Thanks, Radhakrishna(RK) Sripada > > > > > > > Thanks, > > Radhakrishna(RK) Sripada > > 1. https://patchwork.freedesktop.org/series/120683/ > > 2. https://patchwork.freedesktop.org/series/123329/ > > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > > > Signed-off-by: Ville Syrjälä > > > > > --- > > > > > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 11 ++- > > > > > drivers/gpu/drm/i915/gt/intel_ggtt.c | 13 - > > > > > 2 files changed, 22 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > > > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > > > > > index ee237043c302..252fe5cd6ede 100644 > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > > > > > @@ -941,7 +941,16 @@ i
RE: [PATCH] drm/i915/mtl: Fix HDMI/DP PLL clock selection
> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, December 13, 2023 2:05 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika ; Sripada, Radhakrishna
>
> Subject: [PATCH] drm/i915/mtl: Fix HDMI/DP PLL clock selection
>
> Select the HDMI specific PLL clock only for HDMI outputs.
>
> Fixes: 62618c7f117e ("drm/i915/mtl: C20 PLL programming")
> Cc: Mika Kahola
> Cc: Radhakrishna Sripada
LGTM,
Reviewed-by: Radhakrishna Sripada
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 4e6ea71ff6294..884a1da360893 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2468,7 +2468,8 @@ static void intel_program_port_clock_ctl(struct
> intel_encoder *encoder,
>
> val |= XELPDP_FORWARD_CLOCK_UNGATE;
>
> - if (is_hdmi_frl(crtc_state->port_clock))
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
> + is_hdmi_frl(crtc_state->port_clock))
> val |=
> XELPDP_DDI_CLOCK_SELECT(XELPDP_DDI_CLOCK_SELECT_DIV18CLK);
> else
> val |=
> XELPDP_DDI_CLOCK_SELECT(XELPDP_DDI_CLOCK_SELECT_MAXPCLK);
> --
> 2.39.2
RE: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access
Hi Ville,
+Nirmoy
> -Original Message-
> From: Ville Syrjälä
> Sent: Wednesday, December 13, 2023 1:30 AM
> To: Joonas Lahtinen
> Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna
>
> Subject: Re: [PATCH 04/12] drm/i915: Bypass LMEMBAR/GTTMMADR for MTL
> stolen memory access
>
> On Wed, Dec 13, 2023 at 11:09:38AM +0200, Joonas Lahtinen wrote:
> > Quoting Ville Syrjala (2023-12-13 02:42:29)
> > > From: Ville Syrjälä
> > >
> > > On MTL accessing stolen memory via the BARs is somehow borked,
> > > and it can hang the machine. As a workaround let's bypass the
> > > BARs and just go straight to DSMBASE/GSMBASE instead.
> > >
> > > Note that on every other platform this itself would hang the
> > > machine, but on MTL the system firmware is expected to relax
> > > the access permission guarding stolen memory to enable this
> > > workaround, and thus direct CPU accesses should be fine.
> >
> > Shouldn't this have a proper workaround number assigned?
>
> I think there are various numbers, half of which I couldn't even
> find in any database, and the other half I couldn't access for
> whatever reason. So dunno what situation really is apart from
> the firmware clearly implemening its part (since I can poke
> DSM/GSM directly without killing the machine).
>
> RK do you know what we should call this?
Nirmoy previously used Wa_22018444074 in [1].
There were some associated issues Wa_13010847436 and Wa_14019519902
which Nirmoy quoted in [2].
Wa_22018529850 is derived from Wa_22018444074, is targeting the latest Gop
driver change which is installed in bat-mtlp-8 hopefully it should help debug
the issue further.
Regarding the patch itself,
Do we need to carve out the range from e820 the area around DSM if we can
directly access the range from CPU
without the bar?
Thanks,
Radhakrishna(RK) Sripada
1. https://patchwork.freedesktop.org/series/120683/
2. https://patchwork.freedesktop.org/series/123329/
>
> >
> > Regards, Joonas
> >
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 11 ++-
> > > drivers/gpu/drm/i915/gt/intel_ggtt.c | 13 -
> > > 2 files changed, 22 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > > index ee237043c302..252fe5cd6ede 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > > @@ -941,7 +941,16 @@ i915_gem_stolen_lmem_setup(struct
> drm_i915_private *i915, u16 type,
> > > dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M);
> > > }
> > >
> > > - if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
> > > + if (IS_METEORLAKE(i915)) {
> > > + /*
> > > +* Workaround: access via BAR can hang MTL, go directly
> > > to DSM.
> > > +*
> > > +* Normally this would not work but on MTL the system
> > > firmware
> > > +* should have relaxed the access permissions
> > > sufficiently.
> > > +*/
> > > + io_start = intel_uncore_read64(uncore, GEN12_DSMBASE) &
> GEN12_BDSM_MASK;
> > > + io_size = dsm_size;
> > > + } else if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
> > > io_start = 0;
> > > io_size = 0;
> > > } else {
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > > index 21a7e3191c18..ab71d74ec426 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > > @@ -24,6 +24,7 @@
> > > #include "intel_ring.h"
> > > #include "i915_drv.h"
> > > #include "i915_pci.h"
> > > +#include "i915_reg.h"
> > > #include "i915_request.h"
> > > #include "i915_scatterlist.h"
> > > #include "i915_utils.h"
> > > @@ -1152,13 +1153,23 @@ static unsigned int gen6_gttadr_offset(struct
> drm_i915_private *i915)
> > > static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
> > > {
> > > struct drm_i915_private *i915 = ggtt->vm.i915;
> > > + struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> > &
RE: [PATCH 3/3] drm/i915/mtl: Rename the link_bit_rate to clock in C20 pll_state
Thank you for the review. With clean CI pushed the patches upstream.
Regards,
Radhakrishna Sripada
> -Original Message-
> From: Kahola, Mika
> Sent: Friday, December 8, 2023 4:01 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: Taylor, Clinton A
> Subject: RE: [PATCH 3/3] drm/i915/mtl: Rename the link_bit_rate to clock in
> C20
> pll_state
>
> > -Original Message-
> > From: Sripada, Radhakrishna
> > Sent: Friday, December 8, 2023 12:10 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Sripada, Radhakrishna ; Taylor, Clinton
> > A
> ; Kahola, Mika
> >
> > Subject: [PATCH 3/3] drm/i915/mtl: Rename the link_bit_rate to clock in C20
> pll_state
> >
> > With the cleanup of the misleading clock value to avoid extra calculations
> > to
> convert between link_bit_rate and clock, use one
> > standard "clock" field for the c20 pll which works with
> > crtc_state->port_clock
> field.
> >
> > Cc: Clint Taylor
> > Cc: Mika Kahola
>
> Reviewed-by: Mika Kahola
>
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 42 +--
> > .../drm/i915/display/intel_display_types.h| 2 +-
> > 2 files changed, 22 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index d518b55d5150..4e6ea71ff629 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -745,7 +745,7 @@ static const struct intel_c10pll_state * const
> mtl_c10_edp_tables[] = {
> >
> > /* C20 basic DP 1.4 tables */
> > static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > - .link_bit_rate = 162000,
> > + .clock = 162000,
> > .tx = { 0xbe88, /* tx cfg0 */
> > 0x5800, /* tx cfg1 */
> > 0x, /* tx cfg2 */
> > @@ -770,7 +770,7 @@ static const struct intel_c20pll_state mtl_c20_dp_rbr =
> { };
> >
> > static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> > - .link_bit_rate = 27,
> > + .clock = 27,
> > .tx = { 0xbe88, /* tx cfg0 */
> > 0x4800, /* tx cfg1 */
> > 0x, /* tx cfg2 */
> > @@ -795,7 +795,7 @@ static const struct intel_c20pll_state mtl_c20_dp_hbr1
> = { };
> >
> > static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
> > - .link_bit_rate = 54,
> > + .clock = 54,
> > .tx = { 0xbe88, /* tx cfg0 */
> > 0x4800, /* tx cfg1 */
> > 0x, /* tx cfg2 */
> > @@ -820,7 +820,7 @@ static const struct intel_c20pll_state mtl_c20_dp_hbr2
> = { };
> >
> > static const struct intel_c20pll_state mtl_c20_dp_hbr3 = {
> > - .link_bit_rate = 81,
> > + .clock = 81,
> > .tx = { 0xbe88, /* tx cfg0 */
> > 0x4800, /* tx cfg1 */
> > 0x, /* tx cfg2 */
> > @@ -846,7 +846,7 @@ static const struct intel_c20pll_state mtl_c20_dp_hbr3
> = {
> >
> > /* C20 basic DP 2.0 tables */
> > static const struct intel_c20pll_state mtl_c20_dp_uhbr10 = {
> > - .link_bit_rate = 100, /* 10 Gbps */
> > + .clock = 100, /* 10 Gbps */
> > .tx = { 0xbe21, /* tx cfg0 */
> > 0x4800, /* tx cfg1 */
> > 0x, /* tx cfg2 */
> > @@ -870,7 +870,7 @@ static const struct intel_c20pll_state
> mtl_c20_dp_uhbr10 = { };
> >
> > static const struct intel_c20pll_state mtl_c20_dp_uhbr13_5 = {
> > - .link_bit_rate = 135, /* 13.5 Gbps */
> > + .clock = 135, /* 13.5 Gbps */
> > .tx = { 0xbea0, /* tx cfg0 */
> > 0x4800, /* tx cfg1 */
> > 0x, /* tx cfg2 */
> > @@ -895,7 +895,7 @@ static const struct intel_c20pll_state
> mtl_c20_dp_uhbr13_5 = { };
> >
> > static const struct intel_c20pll_state mtl_c20_dp_uhbr20 = {
> > - .link_bit_rate = 200, /* 20 Gbps */
> > + .clock = 200, /* 20 Gbps */
> > .tx = { 0xbe20, /* tx cfg0 */
> > 0x4800, /* tx cfg1 */
> > 0x, /* tx cfg2 */
> > @@ -1514,7 +1514,7 @@ static const struct intel_c10pll_state * const
> mtl_c10_hdmi_tables[] = { };
> >
> > static const struct intel_c20pll_state mtl_c20_hdmi_25_175 = {
> > - .link_bit_rate = 25175,
> > + .clock = 25175,
> > .tx = { 0xbe88, /* tx cfg0 */
> > 0x9800, /* tx cfg1 */
> > 0x, /
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link bitrate to corresponding PLL clock
Hi Mika,
> -Original Message-
> From: Kahola, Mika
> Sent: Tuesday, December 5, 2023 12:28 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link bitrate to
> corresponding PLL clock
>
> > -Original Message-
> > From: Sripada, Radhakrishna
> > Sent: Tuesday, December 5, 2023 3:36 AM
> > To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> > Subject: RE: [Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link bitrate
> > to
> corresponding PLL clock
> >
> > Hi Mika,
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf Of
> > > Mika Kahola
> > > Sent: Monday, December 4, 2023 3:59 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link
> > > bitrate to corresponding PLL clock
> > >
> > > Compute clock during PLL readout. This prevents warn when only c20 phy
> > > is connected during modprobe. The intel_c20pll_calc_port_clock()
> > > function returns link bitrate which in DP2.0 and HDMI cases does not
> > > match with the clock rate. Hence, conversion function is needed to
> > > convert link bitrate to corresponding PLL clock rate.
> > >
> > > while at it, update clock on C10 pll state as well.
> > >
> > > Signed-off-by: Clint Taylor
> > > Signed-off-by: Mika Kahola
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 38
> > > ++-- drivers/gpu/drm/i915/display/intel_cx0_phy.h | 1 +
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> > > 3 files changed, 37 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index 2e6412fc2258..02efe2786c6a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -1871,6 +1871,7 @@ static int intel_c10pll_calc_state(struct
> > > intel_crtc_state *crtc_state, }
> > >
> > > static void intel_c10pll_readout_hw_state(struct intel_encoder
> > > *encoder,
> > > + struct intel_crtc_state *crtc_state,
> > > struct intel_c10pll_state *pll_state)
> > > {
> > > struct drm_i915_private *i915 = to_i915(encoder->base.dev); @@
> > > -1894,6 +1895,7 @@ static void intel_c10pll_readout_hw_state(struct
> > > intel_encoder *encoder,
> > >
> > > pll_state->cmn = intel_cx0_read(i915, encoder->port, lane,
> > > PHY_C10_VDR_CMN(0));
> > > pll_state->tx = intel_cx0_read(i915, encoder->port, lane,
> > > PHY_C10_VDR_TX(0));
> > > + pll_state->clock = crtc_state->port_clock;
> > >
> > > intel_cx0_phy_transaction_end(encoder, wakeref); } @@ -2445,12
> > > +2447,33 @@ static void intel_program_port_clock_ctl(struct
> > > intel_encoder *encoder,
> > >XELPDP_SSC_ENABLE_PLLB, val);
> > > }
> > >
> > > +static int intel_link_bitrate_to_clock(struct intel_encoder *encoder,
> > > +struct intel_crtc_state *crtc_state,
> > > +int link_bit_rate)
> > > +{
> > > + const struct intel_c20pll_state * const *tables;
> > > + int i;
> > > +
> > > + tables = intel_c20_pll_tables_get(crtc_state, encoder);
> > This will produce incorrect result. intel_c20_pll_tables_get depends on
> intel_crtc_has_{dp_encoder,hdmi..} which depends
> > crtc_state->output_types to determine edp/dp/hdmi table which is not
> initialized until later in mtl_ddi_init_config under
> > intel_ddi_get_config -> intel_ddi_read_func_ctl
> >
> > We might be needing a separate sanitization of initial pll state to be done
> > after
> intel_ddi_get_config. Or a special case to handle
> > initial modeset.
> I actually noticed this while testing it that at first we don't even get the
> tables and
> function returns with -EINVAL. Eventually we do get the correct table and
> clock.
> Maybe it would be better to simply use the if-else ladder for those cases that
> differs from link bitrate vs. clock?
I am skeptical about making 2 different entries for the same data. Why don’t we
make
intel_c20_get_dp_rate work on link bit rate numbers which is what
intel_c20pll_calc_port_clock
returns an
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link bitrate to corresponding PLL clock
Hi Mika,
> -Original Message-
> From: Intel-gfx On Behalf Of Mika
> Kahola
> Sent: Monday, December 4, 2023 3:59 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/3] drm/i915/display: Convert link bitrate to
> corresponding PLL clock
>
> Compute clock during PLL readout. This prevents warn when only c20 phy
> is connected during modprobe. The intel_c20pll_calc_port_clock()
> function returns link bitrate which in DP2.0 and HDMI cases does not match
> with the clock rate. Hence, conversion function is needed to convert
> link bitrate to corresponding PLL clock rate.
>
> while at it, update clock on C10 pll state as well.
>
> Signed-off-by: Clint Taylor
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 38 ++--
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 1 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> 3 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 2e6412fc2258..02efe2786c6a 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -1871,6 +1871,7 @@ static int intel_c10pll_calc_state(struct
> intel_crtc_state *crtc_state,
> }
>
> static void intel_c10pll_readout_hw_state(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> struct intel_c10pll_state *pll_state)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> @@ -1894,6 +1895,7 @@ static void intel_c10pll_readout_hw_state(struct
> intel_encoder *encoder,
>
> pll_state->cmn = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_CMN(0));
> pll_state->tx = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_TX(0));
> + pll_state->clock = crtc_state->port_clock;
>
> intel_cx0_phy_transaction_end(encoder, wakeref);
> }
> @@ -2445,12 +2447,33 @@ static void intel_program_port_clock_ctl(struct
> intel_encoder *encoder,
>XELPDP_SSC_ENABLE_PLLB, val);
> }
>
> +static int intel_link_bitrate_to_clock(struct intel_encoder *encoder,
> +struct intel_crtc_state *crtc_state,
> +int link_bit_rate)
> +{
> + const struct intel_c20pll_state * const *tables;
> + int i;
> +
> + tables = intel_c20_pll_tables_get(crtc_state, encoder);
This will produce incorrect result. intel_c20_pll_tables_get depends on
intel_crtc_has_{dp_encoder,hdmi..} which depends crtc_state->output_types
to determine edp/dp/hdmi table which is not initialized until later in
mtl_ddi_init_config under intel_ddi_get_config -> intel_ddi_read_func_ctl
We might be needing a separate sanitization of initial pll state to be done
after
intel_ddi_get_config. Or a special case to handle initial modeset.
--Radhakrishna Sripada
> + if (!tables)
> + return -EINVAL;
> +
> + for (i = 0; tables[i]; i++) {
> + if (link_bit_rate == tables[i]->link_bit_rate)
> + return tables[i]->clock;
> + }
> +
> + return -EINVAL;
> +}
> +
> static void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> struct intel_c20pll_state *pll_state)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> bool cntx;
> intel_wakeref_t wakeref;
> + int clock;
> int i;
>
> wakeref = intel_cx0_phy_transaction_begin(encoder);
> @@ -2500,6 +2523,13 @@ static void intel_c20pll_readout_hw_state(struct
> intel_encoder *encoder,
> }
> }
>
> + pll_state->link_bit_rate = intel_c20pll_calc_port_clock(encoder,
> pll_state);
> + clock = intel_link_bitrate_to_clock(encoder, crtc_state,
> + pll_state->link_bit_rate);
> +
> + if (clock >= 0)
> + pll_state->clock = clock;
> +
> intel_cx0_phy_transaction_end(encoder, wakeref);
> }
>
> @@ -3053,15 +3083,16 @@ static void intel_c10pll_state_verify(const struct
> intel_crtc_state *state,
> }
>
> void intel_cx0pll_readout_hw_state(struct intel_encoder *encoder,
> +struct intel_crtc_state *crtc_state,
> struct intel_cx0pll_state *pll_state)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> enum phy phy = intel_port_to_phy(i915, encoder->port);
>
> if (intel_is_c10phy(i915, phy))
> - intel_c10pll_readout_hw_state(encoder, _state->c10);
> + intel_c10pll_readout_hw_state(encoder, crtc_state, _state-
> >c10);
> else
> - intel_c20pll_readout_hw_state(encoder, _state->c20);
> +
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Fix Wa_22016670082
> -Original Message-
> From: Intel-gfx On Behalf Of
> Sripada,
> Radhakrishna
> Sent: Wednesday, November 22, 2023 10:49 PM
> To: Chauhan, Shekhar ; intel-
> g...@lists.freedesktop.org
> Cc: Roper, Matthew D
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Fix Wa_22016670082
>
>
>
> > -Original Message-
> > From: Chauhan, Shekhar
> > Sent: Wednesday, November 22, 2023 10:34 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Roper, Matthew D ; Sripada, Radhakrishna
> > ; Chauhan, Shekhar
> >
> > Subject: [PATCH v3] drm/i915/mtl: Fix Wa_22016670082
> >
> > Wa_22016670082 is applicable on GT and Media.
> > For GT, an MCR register is required instead of MMIO.
> >
> > v1: Introduce the fix.
> > v2: Minor naming convention change and adding a TODO
> > v3: Enhancing the TODO
> >
> LGTM,
> Reviewed-by: Radhakrishna Sripada
With actual r-b
Reviewed-by: Radhakrishna Sripada
>
> > Signed-off-by: Shekhar Chauhan
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 9de41703fae5..b2a245e3e77f 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -529,7 +529,9 @@
> >
> > #define GEN8_RC6_CTX_INFO _MMIO(0x8504)
> >
> > +/* TODO: Evaluate MCR usage for both Media and GT instances of SQCNT1
> > register. */
> > #define GEN12_SQCNT1 _MMIO(0x8718)
> > +#define GEN12_GT_SQCNT1MCR_REG(0x8718)
> > #define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
> > #define GEN12_SQCNT1_OABPC REG_BIT(29)
> > #define GEN12_STRICT_RAR_ENABLE REG_BIT(23)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 9bc0654efdc0..dbf0c6e536f1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -1644,7 +1644,7 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct
> > i915_wa_list *wal)
> > wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> >
> > /* Wa_22016670082 */
> > - wa_write_or(wal, GEN12_SQCNT1, GEN12_STRICT_RAR_ENABLE);
> > + wa_mcr_write_or(wal, GEN12_GT_SQCNT1,
> > GEN12_STRICT_RAR_ENABLE);
> >
> > if (IS_GFX_GT_IP_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
> > IS_GFX_GT_IP_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0)) {
> > --
> > 2.34.1
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Fix Wa_22016670082
> -Original Message-
> From: Chauhan, Shekhar
> Sent: Wednesday, November 22, 2023 10:34 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Sripada, Radhakrishna
> ; Chauhan, Shekhar
>
> Subject: [PATCH v3] drm/i915/mtl: Fix Wa_22016670082
>
> Wa_22016670082 is applicable on GT and Media.
> For GT, an MCR register is required instead of MMIO.
>
> v1: Introduce the fix.
> v2: Minor naming convention change and adding a TODO
> v3: Enhancing the TODO
>
LGTM,
Reviewed-by: Radhakrishna Sripada
> Signed-off-by: Shekhar Chauhan
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 9de41703fae5..b2a245e3e77f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -529,7 +529,9 @@
>
> #define GEN8_RC6_CTX_INFO_MMIO(0x8504)
>
> +/* TODO: Evaluate MCR usage for both Media and GT instances of SQCNT1
> register. */
> #define GEN12_SQCNT1 _MMIO(0x8718)
> +#define GEN12_GT_SQCNT1 MCR_REG(0x8718)
> #define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
> #define GEN12_SQCNT1_OABPC REG_BIT(29)
> #define GEN12_STRICT_RAR_ENABLEREG_BIT(23)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 9bc0654efdc0..dbf0c6e536f1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1644,7 +1644,7 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
>
> /* Wa_22016670082 */
> - wa_write_or(wal, GEN12_SQCNT1, GEN12_STRICT_RAR_ENABLE);
> + wa_mcr_write_or(wal, GEN12_GT_SQCNT1,
> GEN12_STRICT_RAR_ENABLE);
>
> if (IS_GFX_GT_IP_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
> IS_GFX_GT_IP_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0)) {
> --
> 2.34.1
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/mtl: Fix Wa_22016670082
> -Original Message-
> From: Chauhan, Shekhar
> Sent: Wednesday, November 22, 2023 9:15 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Sripada, Radhakrishna
> ; Chauhan, Shekhar
>
> Subject: [PATCH v2 1/1] drm/i915/mtl: Fix Wa_22016670082
>
> Wa_22016670082 is applicable on GT and Media.
> For GT, an MCR register is required instead of MMIO.
>
The revision history should be captured in the patch not in the cover letter.
> Signed-off-by: Shekhar Chauhan
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 ++
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 9de41703fae5..f77caf81f948 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -529,7 +529,13 @@
>
> #define GEN8_RC6_CTX_INFO_MMIO(0x8504)
>
> +/*
> + * TODO: Change GEN12_SQCNT1 to MTL_MEDIA_SQCNT1 or something
> + * equivalent and also at all the places this reg is currently
> + * being used.
Too descriptive an vague. I would use something like
/* TODO: Evaluate MCR usage for both Media and GT instances of SQCNT1
register. */
Regards,
Radhakrishna(RK) Sripada
> + */
> #define GEN12_SQCNT1 _MMIO(0x8718)
> +#define GEN12_GT_SQCNT1 MCR_REG(0x8718)
> #define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
> #define GEN12_SQCNT1_OABPC REG_BIT(29)
> #define GEN12_STRICT_RAR_ENABLEREG_BIT(23)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 9bc0654efdc0..dbf0c6e536f1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1644,7 +1644,7 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
>
> /* Wa_22016670082 */
> - wa_write_or(wal, GEN12_SQCNT1, GEN12_STRICT_RAR_ENABLE);
> + wa_mcr_write_or(wal, GEN12_GT_SQCNT1,
> GEN12_STRICT_RAR_ENABLE);
>
> if (IS_GFX_GT_IP_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
> IS_GFX_GT_IP_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0)) {
> --
> 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix Wa_22016670082
Hi Shekhar,
> -Original Message-
> From: Intel-gfx On Behalf Of Shekhar
> Chauhan
> Sent: Tuesday, November 21, 2023 9:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D
> Subject: [Intel-gfx] [PATCH] drm/i915/mtl: Fix Wa_22016670082
>
> Wa_22016670082 is applicable on GT and Media.
> For GT, an MCR register is required instead of MMIO.
>
> Signed-off-by: Shekhar Chauhan
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 9de41703fae5..02d1d41fcfe1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -530,6 +530,7 @@
> #define GEN8_RC6_CTX_INFO_MMIO(0x8504)
>
> #define GEN12_SQCNT1 _MMIO(0x8718)
> +#define SQCNT1 MCR_REG(0x8718)
SQCNT1 when defined stand alone, from a naming convention implies that this
register with its current form is applicable to all the platforms supported by
i915 driver,
which clearly is not the case. From a naming perspective, I would suggest to
use something
on the lines of GEN12_GT_SQCNT1 for the MCR_REG. GEN12_SQCNT1 definition above
should eventually be changed to MTL_MEDIA_SQCNT1 and all the places currently
using
GEN12_SQCNT1 should use the appropriate register access api's.
Adding a TODO to the comment above will serve as a documentation for future and
will be
worthwhile to work on while this patch makes progress.
Regards,
Radhakrishna(RK) Sripada
> #define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
> #define GEN12_SQCNT1_OABPC REG_BIT(29)
> #define GEN12_STRICT_RAR_ENABLEREG_BIT(23)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 9bc0654efdc0..34855e1ea1e6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1644,7 +1644,7 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
>
> /* Wa_22016670082 */
> - wa_write_or(wal, GEN12_SQCNT1, GEN12_STRICT_RAR_ENABLE);
> + wa_mcr_write_or(wal, SQCNT1, GEN12_STRICT_RAR_ENABLE);
>
> if (IS_GFX_GT_IP_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
> IS_GFX_GT_IP_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0)) {
> --
> 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915: Read a shadowed mmio register for ggtt flush
Hi Vinay, > -Original Message- > From: dri-devel On Behalf Of > Belgaumkar, Vinay > Sent: Thursday, November 9, 2023 5:02 PM > To: Ville Syrjälä > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Read a shadowed mmio register for > ggtt flush > > > On 11/9/2023 12:35 PM, Ville Syrjälä wrote: > > On Thu, Nov 09, 2023 at 12:01:26PM -0800, Belgaumkar, Vinay wrote: > >> On 11/9/2023 11:30 AM, Ville Syrjälä wrote: > >>> On Thu, Nov 09, 2023 at 11:21:48AM -0800, Vinay Belgaumkar wrote: > >>>> We read RENDER_HEAD as a part of the flush. If GT is in > >>>> deeper sleep states, this could lead to read errors since we are > >>>> not using a forcewake. Safer to read a shadowed register instead. > >>> IIRC shadowing is only thing for writes, not reads. > >> Sure, but reading from a shadowed register does return the cached value > > Does it? I suppose that would make some sense, but I don't recall that > > ever being stated anywhere. At least before the shadow registers > > existed reads would just give you zeroes when not awake. > > > >> (even though we don't care about the vakue here). When GT is in deeper > >> sleep states, it is better to read a shadowed (cached) value instead of > >> trying to attempt an mmio register read without a force wake anyways. > > So you're saying reads from non-shadowed registers fails somehow > > when not awake? How exactly do they fail? And when reading from > > a shadowed register that failure never happens? > > We could hit problems like the one being addressed here - > https://patchwork.freedesktop.org/series/125356/. Reading from a > shadowed register will avoid any needless references(without a wake) to > the MMIO space. Shouldn't hurt to make this change for all gens IMO. The proposed usage looks accurate for the issue described. Reviewed-by: Radhakrishna Sripada --Radhakrishna(RK) Sripada > > Thanks, > > Vinay. > > > > >> Thanks, > >> > >> Vinay. > >> > >>>> Cc: John Harrison > >>>> Cc: Daniele Ceraolo Spurio > >>>> Signed-off-by: Vinay Belgaumkar > >>>> --- > >>>>drivers/gpu/drm/i915/gt/intel_gt.c | 2 +- > >>>>1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > b/drivers/gpu/drm/i915/gt/intel_gt.c > >>>> index ed32bf5b1546..ea814ea5f700 100644 > >>>> --- a/drivers/gpu/drm/i915/gt/intel_gt.c > >>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > >>>> @@ -451,7 +451,7 @@ void intel_gt_flush_ggtt_writes(struct intel_gt *gt) > >>>> > >>>> spin_lock_irqsave(>lock, flags); > >>>> intel_uncore_posting_read_fw(uncore, > >>>> - > >>>> RING_HEAD(RENDER_RING_BASE)); > >>>> + > >>>> RING_TAIL(RENDER_RING_BASE)); > >>>> spin_unlock_irqrestore(>lock, flags); > >>>> } > >>>>} > >>>> -- > >>>> 2.38.1
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d is enabled
Hi Andrzej,
The patch mentioned below does not help with the issue.
Thanks,
RK
> -Original Message-
> From: Hajda, Andrzej
> Sent: Friday, November 3, 2023 2:18 PM
> To: Sripada, Radhakrishna ; Tvrtko Ursulin
> ; intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Vivi, Rodrigo
>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d
> is
> enabled
>
>
>
> On 03.11.2023 16:53, Sripada, Radhakrishna wrote:
> > Hi Tvrtko,
> >
> >> -Original Message-
> >> From: Tvrtko Ursulin
> >> Sent: Friday, November 3, 2023 1:30 AM
> >> To: Sripada, Radhakrishna ; Hajda, Andrzej
> >> ; intel-gfx@lists.freedesktop.org
> >> Cc: Chris Wilson
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when
> >> vt-d
> is
> >> enabled
> >>
> >>
> >> On 02/11/2023 22:14, Sripada, Radhakrishna wrote:
> >>> Hi Tvrtko,
> >>>
> >>>> -Original Message-
> >>>> From: Tvrtko Ursulin
> >>>> Sent: Thursday, November 2, 2023 10:41 AM
> >>>> To: Hajda, Andrzej ; Sripada, Radhakrishna
> >>>> ; intel-gfx@lists.freedesktop.org
> >>>> Cc: Chris Wilson
> >>>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when
> vt-d
> >> is
> >>>> enabled
> >>>>
> >>>>
> >>>> On 02/11/2023 16:58, Andrzej Hajda wrote:
> >>>>> On 02.11.2023 17:06, Radhakrishna Sripada wrote:
> >>>>>> Experiments were conducted with different multipliers to VTD_GUARD
> >> macro
> >>>>>> with multiplier of 185 we were observing occasional pipe faults when
> >>>>>> running kms_cursor_legacy --run-subtest single-bo
> >>>>>>
> >>>>>> There could possibly be an underlying issue that is being
> >>>>>> investigated, for
> >>>>>> now bump the guard pages for MTL.
> >>>>>>
> >>>>>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2017
> >>>>>> Cc: Gustavo Sousa
> >>>>>> Cc: Chris Wilson
> >>>>>> Signed-off-by: Radhakrishna Sripada
> >>>>>> ---
> >>>>>> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
> >>>>>> 1 file changed, 3 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >>>>>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >>>>>> index 3770828f2eaf..b65f84c6bb3f 100644
> >>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >>>>>> @@ -456,6 +456,9 @@ i915_gem_object_pin_to_display_plane(struct
> >>>>>> drm_i915_gem_object *obj,
> >>>>>> if (intel_scanout_needs_vtd_wa(i915)) {
> >>>>>> unsigned int guard = VTD_GUARD;
> >>>>>> + if (IS_METEORLAKE(i915))
> >>>>>> + guard *= 200;
> >>>>>> +
> >>>>> 200 * VTD_GUARD = 200 * 168 * 4K = 131MB
> >>>>>
> >>>>> Looks insanely high, 131MB for padding, if this is before and after it
> >>>>> becomes even 262MB of wasted address per plane. Just signalling, I do
> >>>>> not know if this actually hurts.
> >>>> Yeah this feels crazy. There must be some other explanation which is
> >>>> getting hidden by the crazy amount of padding so I'd rather we figured
> >>>> it out.
> >>>>
> >>>> With 262MiB per fb how many fit in GGTT before eviction hits? N screens
> >>>> with double/triple buffering?
> >>> I believe with this method we will have to limit the no of frame buffers
> >>> in the
> >> system. One alternative
> >>> that worked is to do a proper clear range for the ggtt instead of doing a
> >>> nop.
> >> Although it adds marginal
> >>> time during suspend/resume/boot it does not add restrictions to the no of
> fb's
> >> that can be used.
> >>
> >> And if we remember the guard pages replaced clearing to scratch, to
> >> improve suspend resume times, exactly for improving user experience. :(
> >>
> >> Luckily there is time to fix this properly on MTL one way or the other.
> >> Is it just kms_cursor_legacy --run-subtest single-bo that is affected?
> > I am trying to dump the page table entries at the time of failure for bot
> > the fame
> buffer and if required
> > For the guard pages. Will see if I get some info from there.
> >
> > Yes the test kms_cursor_legacy is used to reliably reproduce. Looking at
> > public
> CI, I also see pipe errors
> > being reported with varying occurrences while running kms_cursor_crc,
> kms_pipe_crc_basic,
> > and kms_plane_scaling. More details on the occurrence can be found here [1].
> >
> > Thanks,
> > RK
> >
> > 1. http://gfx-ci.igk.intel.com/cibuglog-
> ng/results/knownfailures?query_key=d9c3297dd17dda35a6c638eb96b3139bd1a
> 6633c
>
> Could you check if [1] helps?
>
> [1]: https://patchwork.freedesktop.org/series/125926/
>
> Regards
> Andrzej
>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >>
> >>>> Regards,
> >>>>
> >>>> Tvrtko
> >>>>
> >>>> P.S. Where did the 185 from the commit message come from?
> >>> 185 came from experiment to increase the guard size. It is not a standard
> >> number.
> >>> Regards,
> >>> Radhakrishna(RK) Sripada
Re: [Intel-gfx] [PATCH] drm/i915/gt: Temporarily disable CPU caching into DMA for MTL
Hi Jonathan, > -Original Message- > From: Cavitt, Jonathan > Sent: Friday, November 3, 2023 1:15 PM > To: Sripada, Radhakrishna ; intel- > g...@lists.freedesktop.org > Cc: Gupta, saurabhg ; > chris.p.wil...@linux.intel.com > Subject: RE: [Intel-gfx] [PATCH] drm/i915/gt: Temporarily disable CPU caching > into DMA for MTL > > -----Original Message----- > From: Sripada, Radhakrishna > Sent: Friday, November 3, 2023 1:02 PM > To: Cavitt, Jonathan ; > intel-gfx@lists.freedesktop.org > Cc: Gupta, saurabhg ; Cavitt, Jonathan > ; chris.p.wil...@linux.intel.com > Subject: RE: [Intel-gfx] [PATCH] drm/i915/gt: Temporarily disable CPU caching > into DMA for MTL > > > > Hi Jonathan, > > > > > -Original Message- > > > From: Intel-gfx On Behalf Of > Jonathan > > > Cavitt > > > Sent: Thursday, November 2, 2023 10:59 AM > > > To: intel-gfx@lists.freedesktop.org > > > Cc: Gupta, saurabhg ; Cavitt, Jonathan > > > ; chris.p.wil...@linux.intel.com > > > Subject: [Intel-gfx] [PATCH] drm/i915/gt: Temporarily disable CPU caching > > > into > > > DMA for MTL > > > > > > FIXME: It is suspected that some Address Translation Service (ATS) > > > issue on IOMMU is causing CAT errors to occur on some MTL workloads. > > > Applying a write barrier to the ppgtt set entry functions appeared > > > to have no effect, so we must temporarily use I915_MAP_WC in the > > > map_pt_dma class of functions on MTL until a proper ATS solution is > > > found. > > > > > What is the performance impact here? Are we disabling caching only > > for the pte changes/scratch pages or does it extend beyond? > > > I don't actually know what map_pt_dma is used for, but if the name is > indicative of its purpose, it should only impact mappings into the dma > page table. > As for the performance impact, I don't imagine it'll be much. Maybe > a single-digit percentage slowdown? It might actually improve > performance if we're avoiding enough cache misses, but the true > performance impact would have to be measured empirically. > -Jonathan Cavitt > Even I am assuming the performance impact to be low as only pte uncached would be uncached and hence Reviewed-by: Radhakrishna Sripada > > > > > Regards, > > Radhakrishna(RK) Sripada > > > Signed-off-by: Jonathan Cavitt > > > CC: Chris Wilson > > > --- > > > drivers/gpu/drm/i915/gt/intel_gtt.c | 20 > > > 1 file changed, 20 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c > > > b/drivers/gpu/drm/i915/gt/intel_gtt.c > > > index 4fbed27ef0ecc..21719563a602a 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c > > > @@ -95,6 +95,16 @@ int map_pt_dma(struct i915_address_space *vm, > struct > > > drm_i915_gem_object *obj) > > > void *vaddr; > > > > > > type = intel_gt_coherent_map_type(vm->gt, obj, true); > > > + /* > > > + * FIXME: It is suspected that some Address Translation Service (ATS) > > > + * issue on IOMMU is causing CAT errors to occur on some MTL > > > workloads. > > > + * Applying a write barrier to the ppgtt set entry functions appeared > > > + * to have no effect, so we must temporarily use I915_MAP_WC here on > > > + * MTL until a proper ATS solution is found. > > > + */ > > > + if (IS_METEORLAKE(vm->i915)) > > > + type = I915_MAP_WC; > > > + > > > vaddr = i915_gem_object_pin_map_unlocked(obj, type); > > > if (IS_ERR(vaddr)) > > > return PTR_ERR(vaddr); > > > @@ -109,6 +119,16 @@ int map_pt_dma_locked(struct i915_address_space > > > *vm, struct drm_i915_gem_object > > > void *vaddr; > > > > > > type = intel_gt_coherent_map_type(vm->gt, obj, true); > > > + /* > > > + * FIXME: It is suspected that some Address Translation Service (ATS) > > > + * issue on IOMMU is causing CAT errors to occur on some MTL > > > workloads. > > > + * Applying a write barrier to the ppgtt set entry functions appeared > > > + * to have no effect, so we must temporarily use I915_MAP_WC here on > > > + * MTL until a proper ATS solution is found. > > > + */ > > > + if (IS_METEORLAKE(vm->i915)) > > > + type = I915_MAP_WC; > > > + > > > vaddr = i915_gem_object_pin_map(obj, type); > > > if (IS_ERR(vaddr)) > > > return PTR_ERR(vaddr); > > > -- > > > 2.25.1 > > > >
Re: [Intel-gfx] [PATCH] drm/i915/gt: Temporarily disable CPU caching into DMA for MTL
Hi Jonathan, > -Original Message- > From: Intel-gfx On Behalf Of > Jonathan > Cavitt > Sent: Thursday, November 2, 2023 10:59 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gupta, saurabhg ; Cavitt, Jonathan > ; chris.p.wil...@linux.intel.com > Subject: [Intel-gfx] [PATCH] drm/i915/gt: Temporarily disable CPU caching into > DMA for MTL > > FIXME: It is suspected that some Address Translation Service (ATS) > issue on IOMMU is causing CAT errors to occur on some MTL workloads. > Applying a write barrier to the ppgtt set entry functions appeared > to have no effect, so we must temporarily use I915_MAP_WC in the > map_pt_dma class of functions on MTL until a proper ATS solution is > found. > What is the performance impact here? Are we disabling caching only for the pte changes/scratch pages or does it extend beyond? Regards, Radhakrishna(RK) Sripada > Signed-off-by: Jonathan Cavitt > CC: Chris Wilson > --- > drivers/gpu/drm/i915/gt/intel_gtt.c | 20 > 1 file changed, 20 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c > b/drivers/gpu/drm/i915/gt/intel_gtt.c > index 4fbed27ef0ecc..21719563a602a 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gtt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c > @@ -95,6 +95,16 @@ int map_pt_dma(struct i915_address_space *vm, struct > drm_i915_gem_object *obj) > void *vaddr; > > type = intel_gt_coherent_map_type(vm->gt, obj, true); > + /* > + * FIXME: It is suspected that some Address Translation Service (ATS) > + * issue on IOMMU is causing CAT errors to occur on some MTL > workloads. > + * Applying a write barrier to the ppgtt set entry functions appeared > + * to have no effect, so we must temporarily use I915_MAP_WC here on > + * MTL until a proper ATS solution is found. > + */ > + if (IS_METEORLAKE(vm->i915)) > + type = I915_MAP_WC; > + > vaddr = i915_gem_object_pin_map_unlocked(obj, type); > if (IS_ERR(vaddr)) > return PTR_ERR(vaddr); > @@ -109,6 +119,16 @@ int map_pt_dma_locked(struct i915_address_space > *vm, struct drm_i915_gem_object > void *vaddr; > > type = intel_gt_coherent_map_type(vm->gt, obj, true); > + /* > + * FIXME: It is suspected that some Address Translation Service (ATS) > + * issue on IOMMU is causing CAT errors to occur on some MTL > workloads. > + * Applying a write barrier to the ppgtt set entry functions appeared > + * to have no effect, so we must temporarily use I915_MAP_WC here on > + * MTL until a proper ATS solution is found. > + */ > + if (IS_METEORLAKE(vm->i915)) > + type = I915_MAP_WC; > + > vaddr = i915_gem_object_pin_map(obj, type); > if (IS_ERR(vaddr)) > return PTR_ERR(vaddr); > -- > 2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d is enabled
Hi Rodrigo,
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Friday, November 3, 2023 8:35 AM
> To: Sousa, Gustavo
> Cc: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org; Chris Wilson
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d
> is
> enabled
>
> On Thu, Nov 02, 2023 at 01:35:53PM -0300, Gustavo Sousa wrote:
> > Quoting Radhakrishna Sripada (2023-11-02 13:06:44-03:00)
> > >Experiments were conducted with different multipliers to VTD_GUARD macro
> > >with multiplier of 185 we were observing occasional pipe faults when
> > >running kms_cursor_legacy --run-subtest single-bo
> > >
> > >There could possibly be an underlying issue that is being investigated, for
> > >now bump the guard pages for MTL.
> > >
> > >Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2017
> > >Cc: Gustavo Sousa
> > >Cc: Chris Wilson
> > >Signed-off-by: Radhakrishna Sripada
> > >---
> > > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > >index 3770828f2eaf..b65f84c6bb3f 100644
> > >--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > >+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > >@@ -456,6 +456,9 @@ i915_gem_object_pin_to_display_plane(struct
> drm_i915_gem_object *obj,
> > > if (intel_scanout_needs_vtd_wa(i915)) {
> > > unsigned int guard = VTD_GUARD;
> > >
> >
> > I remember trying increasing the guard, but with a much smaller multiplier.
> > So
> > it turns out that using a much higher value did the "trick".
>
> a much smaller multiplier could mess with the flags range?
> it is really hard to understand what of that 'flags' is really those 12 flags
> or what is this 'guard' and where that ends up...
Based on my glance, if the multiplier fits in 32 bits then it should work. But
the
problem here pointed out by Tvrtko is that we are adding awful lot(262 mb per
fb) of padding
in the gurad pages clobbering up the ggtt address pace. Enough(10 to 20) fb's
created we
will fall into the realm of evictions.
Regards,
Radhakrishna(RK) Sripada
>
> >
> > I would add a FIXME comment here to remind us that this is a hack.
> >
> > With the FIXME in place,
> >
> > Reviewed-by: Gustavo Sousa
> >
> > >+if (IS_METEORLAKE(i915))
> > >+guard *= 200;
> > >+
> > > if (i915_gem_object_is_tiled(obj))
> > > guard = max(guard,
> > >
> > > i915_gem_object_get_tile_row_size(obj));
> > >--
> > >2.34.1
> > >
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d is enabled
Hi Tvrtko,
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Friday, November 3, 2023 1:30 AM
> To: Sripada, Radhakrishna ; Hajda, Andrzej
> ; intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d
> is
> enabled
>
>
> On 02/11/2023 22:14, Sripada, Radhakrishna wrote:
> > Hi Tvrtko,
> >
> >> -Original Message-
> >> From: Tvrtko Ursulin
> >> Sent: Thursday, November 2, 2023 10:41 AM
> >> To: Hajda, Andrzej ; Sripada, Radhakrishna
> >> ; intel-gfx@lists.freedesktop.org
> >> Cc: Chris Wilson
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when
> >> vt-d
> is
> >> enabled
> >>
> >>
> >> On 02/11/2023 16:58, Andrzej Hajda wrote:
> >>> On 02.11.2023 17:06, Radhakrishna Sripada wrote:
> >>>> Experiments were conducted with different multipliers to VTD_GUARD
> macro
> >>>> with multiplier of 185 we were observing occasional pipe faults when
> >>>> running kms_cursor_legacy --run-subtest single-bo
> >>>>
> >>>> There could possibly be an underlying issue that is being
> >>>> investigated, for
> >>>> now bump the guard pages for MTL.
> >>>>
> >>>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2017
> >>>> Cc: Gustavo Sousa
> >>>> Cc: Chris Wilson
> >>>> Signed-off-by: Radhakrishna Sripada
> >>>> ---
> >>>> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
> >>>> 1 file changed, 3 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >>>> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >>>> index 3770828f2eaf..b65f84c6bb3f 100644
> >>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >>>> @@ -456,6 +456,9 @@ i915_gem_object_pin_to_display_plane(struct
> >>>> drm_i915_gem_object *obj,
> >>>> if (intel_scanout_needs_vtd_wa(i915)) {
> >>>> unsigned int guard = VTD_GUARD;
> >>>> + if (IS_METEORLAKE(i915))
> >>>> + guard *= 200;
> >>>> +
> >>>
> >>> 200 * VTD_GUARD = 200 * 168 * 4K = 131MB
> >>>
> >>> Looks insanely high, 131MB for padding, if this is before and after it
> >>> becomes even 262MB of wasted address per plane. Just signalling, I do
> >>> not know if this actually hurts.
> >>
> >> Yeah this feels crazy. There must be some other explanation which is
> >> getting hidden by the crazy amount of padding so I'd rather we figured
> >> it out.
> >>
> >> With 262MiB per fb how many fit in GGTT before eviction hits? N screens
> >> with double/triple buffering?
> >
> > I believe with this method we will have to limit the no of frame buffers in
> > the
> system. One alternative
> > that worked is to do a proper clear range for the ggtt instead of doing a
> > nop.
> Although it adds marginal
> > time during suspend/resume/boot it does not add restrictions to the no of
> > fb's
> that can be used.
>
> And if we remember the guard pages replaced clearing to scratch, to
> improve suspend resume times, exactly for improving user experience. :(
>
> Luckily there is time to fix this properly on MTL one way or the other.
> Is it just kms_cursor_legacy --run-subtest single-bo that is affected?
I am trying to dump the page table entries at the time of failure for bot the
fame buffer and if required
For the guard pages. Will see if I get some info from there.
Yes the test kms_cursor_legacy is used to reliably reproduce. Looking at public
CI, I also see pipe errors
being reported with varying occurrences while running kms_cursor_crc,
kms_pipe_crc_basic,
and kms_plane_scaling. More details on the occurrence can be found here [1].
Thanks,
RK
1.
http://gfx-ci.igk.intel.com/cibuglog-ng/results/knownfailures?query_key=d9c3297dd17dda35a6c638eb96b3139bd1a6633c
>
> Regards,
>
> Tvrtko
>
>
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >> P.S. Where did the 185 from the commit message come from?
> > 185 came from experiment to increase the guard size. It is not a standard
> number.
> >
> > Regards,
> > Radhakrishna(RK) Sripada
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d is enabled
Hi Tvrtko,
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, November 2, 2023 10:41 AM
> To: Hajda, Andrzej ; Sripada, Radhakrishna
> ; intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Increase guard pages when vt-d
> is
> enabled
>
>
> On 02/11/2023 16:58, Andrzej Hajda wrote:
> > On 02.11.2023 17:06, Radhakrishna Sripada wrote:
> >> Experiments were conducted with different multipliers to VTD_GUARD macro
> >> with multiplier of 185 we were observing occasional pipe faults when
> >> running kms_cursor_legacy --run-subtest single-bo
> >>
> >> There could possibly be an underlying issue that is being
> >> investigated, for
> >> now bump the guard pages for MTL.
> >>
> >> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2017
> >> Cc: Gustavo Sousa
> >> Cc: Chris Wilson
> >> Signed-off-by: Radhakrishna Sripada
> >> ---
> >> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >> index 3770828f2eaf..b65f84c6bb3f 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> >> @@ -456,6 +456,9 @@ i915_gem_object_pin_to_display_plane(struct
> >> drm_i915_gem_object *obj,
> >> if (intel_scanout_needs_vtd_wa(i915)) {
> >> unsigned int guard = VTD_GUARD;
> >> + if (IS_METEORLAKE(i915))
> >> + guard *= 200;
> >> +
> >
> > 200 * VTD_GUARD = 200 * 168 * 4K = 131MB
> >
> > Looks insanely high, 131MB for padding, if this is before and after it
> > becomes even 262MB of wasted address per plane. Just signalling, I do
> > not know if this actually hurts.
>
> Yeah this feels crazy. There must be some other explanation which is
> getting hidden by the crazy amount of padding so I'd rather we figured
> it out.
>
> With 262MiB per fb how many fit in GGTT before eviction hits? N screens
> with double/triple buffering?
I believe with this method we will have to limit the no of frame buffers in the
system. One alternative
that worked is to do a proper clear range for the ggtt instead of doing a nop.
Although it adds marginal
time during suspend/resume/boot it does not add restrictions to the no of fb's
that can be used.
>
> Regards,
>
> Tvrtko
>
> P.S. Where did the 185 from the commit message come from?
185 came from experiment to increase the guard size. It is not a standard
number.
Regards,
Radhakrishna(RK) Sripada
Re: [Intel-gfx] [PATCH v2] drm/i915/mcr: Hold GT forcewake during steering operations
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, October 19, 2023 10:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Sripada, Radhakrishna
> ; Cavitt, Jonathan
> Subject: [PATCH v2] drm/i915/mcr: Hold GT forcewake during steering operations
>
> The steering control and semaphore registers are inside an "always on"
> power domain with respect to RC6. However there are some issues if
> higher-level platform sleep states are entering/exiting at the same time
> these registers are accessed. Grabbing GT forcewake and holding it over
> the entire lock/steer/unlock cycle ensures that those sleep states have
> been fully exited before we access these registers.
>
> This is expected to become a formally documented/numbered workaround
> soon.
>
> Note that this patch alone isn't expected to have an immediately
> noticeable impact on MCR (mis)behavior; an upcoming pcode firmware
> update will also be necessary to provide the other half of this
> workaround.
>
> v2:
> - Move the forcewake inside the Xe_LPG-specific IP version check. This
>should only be necessary on platforms that have a steering semaphore.
>
LGTM,
Reviewed-by: Radhakrishna Sripada
> Fixes: 4186e2185b4f ("drm/i915/gt: Add dedicated MCR lock")
> Cc: Radhakrishna Sripada
> Cc: Jonathan Cavitt
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index 326c2ed1d99b..34913912d8ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -376,9 +376,26 @@ void intel_gt_mcr_lock(struct intel_gt *gt, unsigned long
> *flags)
>* driver threads, but also with hardware/firmware agents. A dedicated
>* locking register is used.
>*/
> - if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> + if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70)) {
> + /*
> + * The steering control and semaphore registers are inside an
> + * "always on" power domain with respect to RC6. However
> there
> + * are some issues if higher-level platform sleep states are
> + * entering/exiting at the same time these registers are
> + * accessed. Grabbing GT forcewake and holding it over the
> + * entire lock/steer/unlock cycle ensures that those sleep
> + * states have been fully exited before we access these
> + * registers. This wakeref will be released in the unlock
> + * routine.
> + *
> + * This is expected to become a formally documented/numbered
> + * workaround soon.
> + */
> + intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_GT);
> +
> err = wait_for(intel_uncore_read_fw(gt->uncore,
> MTL_STEER_SEMAPHORE)
> == 0x1, 100);
> + }
>
> /*
>* Even on platforms with a hardware lock, we'll continue to grab
> @@ -415,8 +432,11 @@ void intel_gt_mcr_unlock(struct intel_gt *gt, unsigned
> long flags)
> {
> spin_unlock_irqrestore(>mcr_lock, flags);
>
> - if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> + if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70)) {
> intel_uncore_write_fw(gt->uncore, MTL_STEER_SEMAPHORE,
> 0x1);
> +
> + intel_uncore_forcewake_put(gt->uncore, FORCEWAKE_GT);
> + }
> }
>
> /**
> --
> 2.41.0
Re: [Intel-gfx] [PATCH] drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned
Fixes: 619a06dba6fa ("drm/i915/mtl: Reset only one lane in case of MFD")
With that pushed the patch with mentioned nits. Thank you for the patch and
review.
-- Radhakrishna Sripada
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Thursday, October 5, 2023 6:47 PM
> To: Sousa, Gustavo ; Almahallawy, Khaled
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/cx0: Only clear/set the Pipe Reset
> bit of
> the PHY Lanes Owned
>
> On Thu, 05 Oct 2023, Gustavo Sousa wrote:
> > Quoting Khaled Almahallawy (2023-10-04 21:13:10-03:00)
> >>Currently, with MFD/pin assignment D, the driver clears the pipe reset bit
> >>of lane 1 which is not owned by display. This causes the display
> >>to block S0iX.
> >>
> >>By not clearing this bit for lane 1 and keeping whatever default, S0ix
> >>started to work. This is already what the driver does at the end
> >>of the phy lane reset sequence (Step#8)
> >>
> >>Bspec: 65451
> >>
> >
> > We should not have blank lines in the trailers section. This could be fixed
> > while applying.
>
> Agreed.
>
> >
> >>Cc: Mika Kahola
> >>Cc: Gustavo Sousa
> >>Signed-off-by: Khaled Almahallawy
> >
> > Nice fix. Thanks!
> >
> > Reviewed-by: Gustavo Sousa
> >
> >>---
> >> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >>index abd607b564f1..f653b83a7d4f 100644
> >>--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >>+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >>@@ -2596,8 +2596,7 @@ static void intel_cx0_phy_lane_reset(struct
> drm_i915_private *i915,
> >> drm_warn(>drm, "PHY %c failed to bring out of SOC
> >> reset after
> %dus.\n",
> >> phy_name(phy),
> XELPDP_PORT_BUF_SOC_READY_TIMEOUT_US);
> >>
> >>-intel_de_rmw(i915, XELPDP_PORT_BUF_CTL2(port),
> >>- XELPDP_LANE_PIPE_RESET(0) | XELPDP_LANE_PIPE_RESET(1),
> >>+intel_de_rmw(i915, XELPDP_PORT_BUF_CTL2(port), lane_pipe_reset,
> >> lane_pipe_reset);
> >>
> >> if (__intel_de_wait_for_register(i915, XELPDP_PORT_BUF_CTL2(port),
> >>--
> >>2.25.1
> >>
>
> --
> Jani Nikula, Intel
Re: [Intel-gfx] [PATCH] drm/i915/cx0: prefer forward declarations over includes
> -Original Message- > From: Nikula, Jani > Sent: Thursday, September 21, 2023 9:23 PM > To: intel-gfx@lists.freedesktop.org > Cc: Nikula, Jani ; Sripada, Radhakrishna > > Subject: [PATCH] drm/i915/cx0: prefer forward declarations over includes > > Avoid including the world from headers when forward declarations > suffice. > > Cc: Radhakrishna Sripada LGTM, Reviewed-by: Radhakrishna Sripada > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_cx0_phy.h | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h > b/drivers/gpu/drm/i915/display/intel_cx0_phy.h > index 4c4db5cdcbd0..912e0eeb0be3 100644 > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h > @@ -10,14 +10,15 @@ > #include > #include > > -#include "i915_drv.h" > -#include "intel_display_types.h" > - > -struct drm_i915_private; > -struct intel_encoder; > -struct intel_crtc_state; > enum icl_port_dpll_id; > enum phy; > +struct drm_i915_private; > +struct intel_atomic_state; > +struct intel_c10pll_state; > +struct intel_c20pll_state; > +struct intel_crtc_state; > +struct intel_encoder; > +struct intel_hdmi; > > bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy); > void intel_mtl_pll_enable(struct intel_encoder *encoder, > @@ -44,4 +45,5 @@ void intel_cx0_phy_set_signal_levels(struct intel_encoder > *encoder, >const struct intel_crtc_state *crtc_state); > int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi *hdmi, int clock); > int intel_mtl_tbt_calc_port_clock(struct intel_encoder *encoder); > + > #endif /* __INTEL_CX0_PHY_H__ */ > -- > 2.39.2
Re: [Intel-gfx] [PATCH] drm/i915: Zap some empty lines
> -Original Message- > From: dri-devel On Behalf Of Tvrtko > Ursulin > Sent: Wednesday, September 20, 2023 2:27 PM > To: Intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Srivatsa, Anusha ; Bhadane, Dnyaneshwar > ; Sripada, Radhakrishna > ; Ursulin, Tvrtko > Subject: [PATCH] drm/i915: Zap some empty lines > > From: Tvrtko Ursulin > > Recent refactoring left an unsightly block of empty lines. Remove them. > > Signed-off-by: Tvrtko Ursulin > Cc: Dnyaneshwar Bhadane > Cc: Anusha Srivatsa > Cc: Radhakrishna Sripada LGTM, Reviewed-by: Radhakrishna Sripada > --- > drivers/gpu/drm/i915/i915_drv.h | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 87ffc477c3b1..511eba3bbdba 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -646,13 +646,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, > #define IS_TIGERLAKE_UY(i915) \ > IS_SUBPLATFORM(i915, INTEL_TIGERLAKE, INTEL_SUBPLATFORM_UY) > > - > - > - > - > - > - > - > #define IS_XEHPSDV_GRAPHICS_STEP(__i915, since, until) \ > (IS_XEHPSDV(__i915) && IS_GRAPHICS_STEP(__i915, since, until)) > > -- > 2.39.2
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Drop force_probe requirement
Hi Rodrigo/Andi,
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, September 6, 2023 7:38 PM
> To: Andi Shyti
> Cc: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Drop force_probe requirement
>
> On Wed, Sep 06, 2023 at 11:25:35AM +0200, Andi Shyti wrote:
> > Hi Radhakrishna,
> >
> > On Tue, Sep 05, 2023 at 12:36:24PM -0700, Radhakrishna Sripada wrote:
> > > Meteorlake has been very usable for a while now, all of uapi changes
> > > related to fundamental platform usage have been finalized and all
> > > required firmware blobs are available. Recent CI results have also
> > > been healthy, so we're ready to drop the force_probe requirement and
> > > enable the platform by default.
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Tvrtko Ursulin
> > > Cc: Joonas Lahtinen
> > > Cc: Jani Nikula
> > > Signed-off-by: Radhakrishna Sripada
> >
> > Please keep me in the loop as well... It's been a year I've been
> > working for this patch to work :)
Sure will do.
> >
> > > ---
> > > drivers/gpu/drm/i915/i915_pci.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> > > index df7c261410f7..fe748906c06f 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -836,7 +836,6 @@ static const struct intel_device_info mtl_info = {
> > > .has_pxp = 1,
> > > .memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
> > > .platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
> > > - .require_force_probe = 1,
> >
> > What's the thinking behind this patch? Are you trying to
> > understand how CI behaves?
>
> CI uses kernel config to force_probe. MTL is already being tested there.
> Also there's no 'CI' or 'HAX' tag on this patch.
> So I would assume this is the ask to remove the protection.
> But based on this question from Andi and knowing that he is working on
> the MTL w/a I'm assuming that this is not the right time yet to remove
> this protection.
>
> Please ensure all the diligence is taken before sending this patch again.
>
> Also ensure that the current CI failures are fixed (gt_pm and gt_engines)
> and that CI has a stable green picture.
Sure Rodrigo. I believe the changes in
https://patchwork.freedesktop.org/series/123329/
are significant enough to not remove force_probe at this time.
Will wait for a later time till CI comes clean.
Thanks,
Radhakrishna
>
> Thanks,
> Rodrigo.
>
> >
> > Andi
> >
> > > MTL_CACHELEVEL,
> > > };
> > >
> > > --
> > > 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout threshold
Hi Gustavo,
> -Original Message-
> From: Sousa, Gustavo
> Sent: Monday, August 28, 2023 2:46 PM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus
> timeout threshold
>
> Quoting Sripada, Radhakrishna (2023-08-28 17:30:19-03:00)
> >Hi Gustavo,
>
> Hi, RK.
>
> Thanks for the feedback! Please, see my replies below.
>
> >
> >> -Original Message-
> >> From: Intel-gfx On Behalf Of
> Gustavo
> >> Sousa
> >> Sent: Monday, August 28, 2023 10:34 AM
> >> To: intel-gfx@lists.freedesktop.org
> >> Subject: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus
> timeout
> >> threshold
> >>
> >> We have experienced timeout issues when accessing C20 SRAM registers.
> >This wording is misleading. It seems to imply that we directly access SRAM
> >registers via msg bus but the reads/writes go through intermediate registers
> >and it is this read/write that is failing. Adding extra clarity here would
> >be helpful.
>
> Hm... Okay. I thought that would already be implied to someone familiar with
> the
> code. What about:
>
> s/when accessing/when going through the sequence to access/
This is better to indicate that it is not direct access.
>
> ?
>
> >
> >> Experimentation showed that bumping the message bus timer threshold
> >> helped on getting display Type-C connection on the C20 PHY to work.
> >>
> >> While the timeout is still under investigation with the HW team, having
> >> logic to allow forward progress (with the proper warnings) seems useful.
> >> Thus, let's bump the threshold when a timeout is detected.
> >>
> >> The maximum value of 0x200 pclk cycles was somewhat arbitrary - 2x the
> >> default value. That value was successfully tested on real hardware that
> >> was displaying timeouts otherwise.
> >>
> >> BSpec: 65156
> >> Signed-off-by: Gustavo Sousa
> >> ---
> >> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 41 +++
> >> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 12 ++
> >> 2 files changed, 53 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> index dd489b50ad60..55d2333032e3 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> @@ -5,6 +5,7 @@
> >>
> >> #include
> >> #include
> >> +#include
> >> #include "i915_reg.h"
> >> #include "intel_cx0_phy.h"
> >> #include "intel_cx0_phy_regs.h"
> >> @@ -29,6 +30,8 @@
> >> #define INTEL_CX0_LANE1BIT(1)
> >> #define INTEL_CX0_BOTH_LANES(INTEL_CX0_LANE1 |
> >> INTEL_CX0_LANE0)
> >>
> >> +#define INTEL_CX0_MSGBUS_TIMER_VAL_MAX0x200
> >> +
> >> bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
> >> {
> >> if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
> >> @@ -119,6 +122,43 @@ static void intel_cx0_bus_reset(struct
> drm_i915_private
> >> *i915, enum port port, i
> >> intel_clear_response_ready_flag(i915, port, lane);
> >> }
> >>
> >> +/*
> >> + * Check if there was a timeout detected by the hardware in the message
> >> bus
> >> + * and bump the threshold if so.
> >> + */
> >> +static void intel_cx0_bus_check_and_bump_timer(struct drm_i915_private
> >> *i915,
> >> + enum port port, int lane)
> >> +{
> >> +enum phy phy = intel_port_to_phy(i915, port);
> >> +i915_reg_t reg;
> >> +u32 val;
> >> +u32 timer_val;
> >> +
> >> +reg = XELPDP_PORT_MSGBUS_TIMER(port, lane);
> >> +val = intel_de_read(i915, reg);
> >> +
> >> +if (!(val & XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT)) {
> >> +drm_warn(>drm,
> >> + "PHY %c lane %d: hardware did not detect a
> >> timeout\n",
> >> + phy_name(phy), lane);
> >> +return;
> >> +}
> >> +
> >> +timer_val =
> >> REG_FIELD_GET(XELPDP_PORT_MSGBUS_TIMER_VAL_MAS
Re: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout threshold
Hi Gustavo,
> -Original Message-
> From: Intel-gfx On Behalf Of Gustavo
> Sousa
> Sent: Monday, August 28, 2023 10:34 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout
> threshold
>
> We have experienced timeout issues when accessing C20 SRAM registers.
This wording is misleading. It seems to imply that we directly access SRAM
registers via msg bus but the reads/writes go through intermediate registers
and it is this read/write that is failing. Adding extra clarity here would be
helpful.
> Experimentation showed that bumping the message bus timer threshold
> helped on getting display Type-C connection on the C20 PHY to work.
>
> While the timeout is still under investigation with the HW team, having
> logic to allow forward progress (with the proper warnings) seems useful.
> Thus, let's bump the threshold when a timeout is detected.
>
> The maximum value of 0x200 pclk cycles was somewhat arbitrary - 2x the
> default value. That value was successfully tested on real hardware that
> was displaying timeouts otherwise.
>
> BSpec: 65156
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 41 +++
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 12 ++
> 2 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index dd489b50ad60..55d2333032e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
> #include "i915_reg.h"
> #include "intel_cx0_phy.h"
> #include "intel_cx0_phy_regs.h"
> @@ -29,6 +30,8 @@
> #define INTEL_CX0_LANE1 BIT(1)
> #define INTEL_CX0_BOTH_LANES (INTEL_CX0_LANE1 |
> INTEL_CX0_LANE0)
>
> +#define INTEL_CX0_MSGBUS_TIMER_VAL_MAX 0x200
> +
> bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
> {
> if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
> @@ -119,6 +122,43 @@ static void intel_cx0_bus_reset(struct drm_i915_private
> *i915, enum port port, i
> intel_clear_response_ready_flag(i915, port, lane);
> }
>
> +/*
> + * Check if there was a timeout detected by the hardware in the message bus
> + * and bump the threshold if so.
> + */
> +static void intel_cx0_bus_check_and_bump_timer(struct drm_i915_private
> *i915,
> +enum port port, int lane)
> +{
> + enum phy phy = intel_port_to_phy(i915, port);
> + i915_reg_t reg;
> + u32 val;
> + u32 timer_val;
> +
> + reg = XELPDP_PORT_MSGBUS_TIMER(port, lane);
> + val = intel_de_read(i915, reg);
> +
> + if (!(val & XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT)) {
> + drm_warn(>drm,
> + "PHY %c lane %d: hardware did not detect a
> timeout\n",
> + phy_name(phy), lane);
> + return;
> + }
> +
> + timer_val =
> REG_FIELD_GET(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK, val);
> +
> + if (timer_val == INTEL_CX0_MSGBUS_TIMER_VAL_MAX)
> + return;
> +
> + timer_val = min(2 * timer_val,
> (u32)INTEL_CX0_MSGBUS_TIMER_VAL_MAX);
^ is this cast necessary?
> + val &= ~XELPDP_PORT_MSGBUS_TIMER_VAL_MASK;
> + val |= REG_FIELD_PREP(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK,
> timer_val);
We do not use REG_FIELD_PREP in the function. Instead we use it in
register definition in intel_cx0_phy_regs.h.
Thanks,
Radhakrishna Sripada
> +
> + drm_dbg_kms(>drm,
> + "PHY %c lane %d: increasing msgbus timer threshold to
> %#x\n",
> + phy_name(phy), lane, timer_val);
> + intel_de_write(i915, reg, val);
> +}
> +
> static int intel_cx0_wait_for_ack(struct drm_i915_private *i915, enum port
> port,
> int command, int lane, u32 *val)
> {
> @@ -132,6 +172,7 @@ static int intel_cx0_wait_for_ack(struct
> drm_i915_private *i915, enum port port,
>XELPDP_MSGBUS_TIMEOUT_SLOW,
> val)) {
> drm_dbg_kms(>drm, "PHY %c Timeout waiting for
> message ACK. Status: 0x%x\n",
> phy_name(phy), *val);
> + intel_cx0_bus_check_and_bump_timer(i915, port, lane);
> intel_cx0_bus_reset(i915, port, lane);
> return -ETIMEDOUT;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> index cb5d1be2ba19..17cc3385aabb 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> @@ -110,6 +110,18 @@
> #define CX0_P4PG_STATE_DISABLE 0xC
> #define CX0_P2_STATE_RESET 0x2
>
> +#define _XELPDP_PORT_MSGBUS_TIMER_LN0_A
> 0x640d8
> +#define _XELPDP_PORT_MSGBUS_TIMER_LN0_B
> 0x641d8
>
Re: [Intel-gfx] [topic/core-for-ci v2] iommu/vt-d: Check domain flags before setting snp bit in page-control
> -Original Message-
> From: Rodrigo Vivi
> Sent: Friday, August 25, 2023 10:24 AM
> To: Sripada, Radhakrishna
> Cc: Jani Nikula ;
> intel-gfx@lists.freedesktop.org;
> Raj, Ashok
> Subject: Re: [Intel-gfx] [topic/core-for-ci v2] iommu/vt-d: Check domain flags
> before setting snp bit in page-control
>
> On Fri, Aug 25, 2023 at 02:15:27PM +, Sripada, Radhakrishna wrote:
> > I was trying this as a solution for the Pipe fault errors. However, I still
> > see
> > The pipe fault errors which do not occur all the time.
>
> We should avoid overloading CI with tests. But if needed because we cannot
> reproduce locally but only on CI, please use the try-bot list instead of
> this one.
>
> And in the very last case where this list needs to be used, please use
> another prefix like CI or HAX, but not the topic/core-for-ci, otherwise
> we will think you are already asking to get that merged there.
Sure will update that. This is a tricky bug that resurfaced after removing
Iommu=pt kernel command line. I already took down one CI resume system for
debug but the issue occurrence now seems to be intermittent and difficult to
narrow down.
Anyways thank you Rodrigo will add the CI tag for later if try bot does not
help.
Thanks,
Radhakrishna Sripada
>
> >
> > Will update the explanation in my follow up patches.
>
> >
> > Thanks,
> > Radhakrishna Sripada
> >
> > > -Original Message-
> > > From: Jani Nikula
> > > Sent: Thursday, August 24, 2023 11:54 PM
> > > To: Sripada, Radhakrishna ; intel-
> > > g...@lists.freedesktop.org
> > > Cc: Raj, Ashok
> > > Subject: Re: [Intel-gfx] [topic/core-for-ci v2] iommu/vt-d: Check domain
> > > flags
> > > before setting snp bit in page-control
> > >
> > > On Thu, 24 Aug 2023, Radhakrishna Sripada
>
> > > wrote:
> > > > From: Ashok Raj
> > > >
> > >
> > > The *why* goes here, along with a link to a gitlab issue.
> > >
> > > Please don't expect topic/core-for-ci to have lower standards than any
> > > other branches. That's not the case. On the contrary, you'll need the
> > > *additional* justification for the commit being in topic/core-for-ci,
> > > and the gitlab issue.
> > >
> > >
> > > BR,
> > > Jani.
> > >
> > >
> > > > Signed-off-by: Ashok Raj
> > > > Signed-off-by: Radhakrishna Sripada
> > > > ---
> > > > drivers/iommu/intel/iommu.c | 2 +-
> > > > drivers/iommu/intel/pasid.c | 2 +-
> > > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> > > > index 5c8c5cdc36cf..71da6f818e96 100644
> > > > --- a/drivers/iommu/intel/iommu.c
> > > > +++ b/drivers/iommu/intel/iommu.c
> > > > @@ -2150,7 +2150,7 @@ __domain_mapping(struct dmar_domain
> *domain,
> > > unsigned long iov_pfn,
> > > > if ((prot & (DMA_PTE_READ|DMA_PTE_WRITE)) == 0)
> > > > return -EINVAL;
> > > >
> > > > - attr = prot & (DMA_PTE_READ | DMA_PTE_WRITE | DMA_PTE_SNP);
> > > > + attr = prot & (DMA_PTE_READ | DMA_PTE_WRITE);
> > > > attr |= DMA_FL_PTE_PRESENT;
> > > > if (domain->use_first_level) {
> > > > attr |= DMA_FL_PTE_XD | DMA_FL_PTE_US |
> > > DMA_FL_PTE_ACCESS;
> > > > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
> > > > index c5d479770e12..a057ecf84d82 100644
> > > > --- a/drivers/iommu/intel/pasid.c
> > > > +++ b/drivers/iommu/intel/pasid.c
> > > > @@ -538,7 +538,7 @@ int intel_pasid_setup_first_level(struct intel_iommu
> > > *iommu,
> > > > if (flags & PASID_FLAG_FL5LP)
> > > > pasid_set_flpm(pte, 1);
> > > >
> > > > - if (flags & PASID_FLAG_PAGE_SNOOP)
> > > > + if ((flags & PASID_FLAG_PAGE_SNOOP) && ecap_sc_support(iommu-
> > > >ecap))
> > > > pasid_set_pgsnp(pte);
> > > >
> > > > pasid_set_domain_id(pte, did);
> > >
> > > --
> > > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [topic/core-for-ci v2] iommu/vt-d: Check domain flags before setting snp bit in page-control
I was trying this as a solution for the Pipe fault errors. However, I still see
The pipe fault errors which do not occur all the time.
Will update the explanation in my follow up patches.
Thanks,
Radhakrishna Sripada
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, August 24, 2023 11:54 PM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: Raj, Ashok
> Subject: Re: [Intel-gfx] [topic/core-for-ci v2] iommu/vt-d: Check domain flags
> before setting snp bit in page-control
>
> On Thu, 24 Aug 2023, Radhakrishna Sripada
> wrote:
> > From: Ashok Raj
> >
>
> The *why* goes here, along with a link to a gitlab issue.
>
> Please don't expect topic/core-for-ci to have lower standards than any
> other branches. That's not the case. On the contrary, you'll need the
> *additional* justification for the commit being in topic/core-for-ci,
> and the gitlab issue.
>
>
> BR,
> Jani.
>
>
> > Signed-off-by: Ashok Raj
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/iommu/intel/iommu.c | 2 +-
> > drivers/iommu/intel/pasid.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> > index 5c8c5cdc36cf..71da6f818e96 100644
> > --- a/drivers/iommu/intel/iommu.c
> > +++ b/drivers/iommu/intel/iommu.c
> > @@ -2150,7 +2150,7 @@ __domain_mapping(struct dmar_domain *domain,
> unsigned long iov_pfn,
> > if ((prot & (DMA_PTE_READ|DMA_PTE_WRITE)) == 0)
> > return -EINVAL;
> >
> > - attr = prot & (DMA_PTE_READ | DMA_PTE_WRITE | DMA_PTE_SNP);
> > + attr = prot & (DMA_PTE_READ | DMA_PTE_WRITE);
> > attr |= DMA_FL_PTE_PRESENT;
> > if (domain->use_first_level) {
> > attr |= DMA_FL_PTE_XD | DMA_FL_PTE_US |
> DMA_FL_PTE_ACCESS;
> > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
> > index c5d479770e12..a057ecf84d82 100644
> > --- a/drivers/iommu/intel/pasid.c
> > +++ b/drivers/iommu/intel/pasid.c
> > @@ -538,7 +538,7 @@ int intel_pasid_setup_first_level(struct intel_iommu
> *iommu,
> > if (flags & PASID_FLAG_FL5LP)
> > pasid_set_flpm(pte, 1);
> >
> > - if (flags & PASID_FLAG_PAGE_SNOOP)
> > + if ((flags & PASID_FLAG_PAGE_SNOOP) && ecap_sc_support(iommu-
> >ecap))
> > pasid_set_pgsnp(pte);
> >
> > pasid_set_domain_id(pte, did);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v1 00/14] Replace acronym with full platform name in defines
Thank you for the patches and the reviews. Thank you Rodrigo for the backmerge to apply the patches. Pushed! --Radhakrishna(RK) Sripada > -Original Message- > From: Intel-gfx On Behalf Of > Dnyaneshwar Bhadane > Sent: Tuesday, August 1, 2023 6:54 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v1 00/14] Replace acronym with full platform name > in defines > > Replacing the acronym used in platform/sub platform defines. > This series covers Haswell, Broadwell, Skylake, Kabylake, Coffeelake, > Cometlake, Rocketlake, Jasperlake, Elkhartlake, Tigerlake, Alderlake, > platoform define.This way there is a consistent pattern > to how platforms are referred.splitting to per paltform for easier > cherrypicks, if needed. > > For the review comment and Reviewed by please refer the link below, > 1 https://patchwork.freedesktop.org/series/121387 > 2 https://patchwork.freedesktop.org/series/119380 > > v2: > - Reordered patches by incrementing platform generations.(Anusha) > - Changeed the commit subject with lowercase platform names. > v3: > - The IS_PLATFORM_(DISPLAY/MEDIA/GRAPHICS)_STEPS replace with Unrolled > format. i.e. IS_PLATFORM_FULL_NAME () && IS_DISPLAY_STEPS() > > v4: > - Removed the MTL platform from the renaming series (Mat Ropper) > - Removed the unused display steps macro. > > v5: > - Resolved valid checkpatch warning > > > Anusha Srivatsa (1): > drm/i915/adln: s/ADLP/ALDERLAKE_P in ADLN defines > > Dnyaneshwar Bhadane (13): > drm/i915/hsw: s/HSW/HASWELL for platform/subplatform defines > drm/i915/bdw: s/BDW/BROADWELL for platform/subplatform defines > drm/i915/skl: s/SKL/SKYLAKE for platform/subplatform defines > drm/i915/kbl: s/KBL/KABYLAKE for platform/subplatform defines > drm/i915/cfl: s/CFL/COFFEELAKE for platform/subplatform defines > drm/i915/cml: s/CML/COMETLAKE for platform/subplatform defines > drm/i915/rkl: s/RKL/ROCKETLAKE for platform/subplatform defines > drm/i915/jsl: s/JSL/JASPERLAKE for platform/subplatform defines > drm/i915/tgl: s/TGL/TIGERLAKE for platform/subplatform defines > drm/i915/adlp: s/ADLP/ALDERLAKE_P for display and graphics step > drm/i915/rplp: s/ADLP_RPLP/RAPTORLAKE_P for RPLP defines > drm/i915/rplu: s/ADLP_RPLU/RAPTORLAKE_U in RPLU defines > drm/i915/adls: s/ADLS_RPLS/RAPTORLAKE_S in platform and subplatform > defines > > drivers/gpu/drm/i915/display/icl_dsi.c| 5 +- > drivers/gpu/drm/i915/display/intel_cdclk.c| 14 +-- > .../gpu/drm/i915/display/intel_combo_phy.c| 7 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 7 +- > .../drm/i915/display/intel_ddi_buf_trans.c| 10 +- > drivers/gpu/drm/i915/display/intel_display.c | 7 +- > .../drm/i915/display/intel_display_device.c | 2 +- > .../drm/i915/display/intel_display_device.h | 2 +- > .../drm/i915/display/intel_display_power.c| 2 +- > drivers/gpu/drm/i915/display/intel_dp.c | 4 +- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 33 --- > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +- > .../gpu/drm/i915/display/intel_pch_refclk.c | 2 +- > drivers/gpu/drm/i915/display/intel_psr.c | 10 +- > .../drm/i915/display/skl_universal_plane.c| 6 +- > drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +- > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +- > drivers/gpu/drm/i915/gt/intel_gt.c| 2 +- > drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 +-- > .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +- > 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_driver.c| 2 +- > drivers/gpu/drm/i915/i915_drv.h | 94 +++ > 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 | 18 ++-- > 28 files changed, 127 insertions(+), 142 deletions(-) > > -- > 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap
Hi Tvrtko,
The changes makes sense and based on the description looks good.
I am bit skeptical about the exec buffer failure reported by ci hence,
withholding the r-b for now. If you believe the CI failure is unrelated
please feel free to add my r-b.
On a side note on platforms with non-coherent ggtt do we really
need to use the barriers twice under intel_gt_flush_ggtt_writes?
--Radhakrishna(RK) Sripada
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Monday, July 24, 2023 5:57 AM
> To: Intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Ursulin, Tvrtko ; Sripada, Radhakrishna
> ; sta...@vger.kernel.org
> Subject: [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of
> i915_vma_pin_iomap
>
> From: Tvrtko Ursulin
>
> Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is
> available")
> added a code path which does not map via GGTT, but was still setting the
> ggtt write bit, and so triggering the GGTT flushing.
>
> Fix it by not setting that bit unless the GGTT mapping path was used, and
> replace the flush with wmb() in i915_vma_flush_writes().
>
> This also works for the i915_gem_object_pin_map path added in
> d976521a995a ("drm/i915: extend i915_vma_pin_iomap()").
>
> It is hard to say if the fix has any observable effect, given that the
> write-combine buffer gets flushed from intel_gt_flush_ggtt_writes too, but
> apart from code clarity, skipping the needless GGTT flushing could be
> beneficial on platforms with non-coherent GGTT. (See the code flow in
> intel_gt_flush_ggtt_writes().)
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is
> available")
> References: d976521a995a ("drm/i915: extend i915_vma_pin_iomap()")
> Cc: Radhakrishna Sripada
> Cc: # v5.14+
> ---
> drivers/gpu/drm/i915/i915_vma.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c
> b/drivers/gpu/drm/i915/i915_vma.c
> index ffb425ba591c..f2b626cd2755 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -602,7 +602,9 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma
> *vma)
> if (err)
> goto err_unpin;
>
> - i915_vma_set_ggtt_write(vma);
> + if (!i915_gem_object_is_lmem(vma->obj) &&
> + i915_vma_is_map_and_fenceable(vma))
> + i915_vma_set_ggtt_write(vma);
>
> /* NB Access through the GTT requires the device to be awake. */
> return page_mask_bits(ptr);
> @@ -617,6 +619,8 @@ void i915_vma_flush_writes(struct i915_vma *vma)
> {
> if (i915_vma_unset_ggtt_write(vma))
> intel_gt_flush_ggtt_writes(vma->vm->gt);
> + else
> + wmb(); /* Just flush the write-combine buffer. */
> }
>
> void i915_vma_unpin_iomap(struct i915_vma *vma)
> --
> 2.39.2
Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
Hi Tvrtko,
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Friday, July 21, 2023 1:17 AM
> To: Sripada, Radhakrishna ; Yang, Fei
> ; intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Ville Syrjälä ;
> Wilson,
> Chris P
> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>
>
> On 20/07/2023 18:02, Sripada, Radhakrishna wrote:
> > Hi Tvrtko,
> >
> >> -Original Message-
> >> From: Tvrtko Ursulin
> >> Sent: Thursday, July 20, 2023 2:17 AM
> >> To: Yang, Fei ; Sripada, Radhakrishna
> >> ; intel-gfx@lists.freedesktop.org
> >> Cc: sta...@vger.kernel.org; Ville Syrjälä ;
> Wilson,
> >> Chris P
> >> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
> >>
> >>
> >> On 19/07/2023 21:53, Yang, Fei wrote:
> >>>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> >>>>> Dpt objects that are created from internal get evicted when there is
> >>>>> memory pressure and do not get restored when pinned during scanout.
> >>>>> The pinned page table entries look corrupted and programming the
> >>>>> display engine with the incorrect pte's result in DE throwing pipe
> >>>>> faults.
> >>>>>
> >>>>> Create DPT objects from shmem and mark the object as dirty when
> >>>>> pinning so that the object is restored when shrinker evicts an unpinned
> >> buffer object.
> >>>>>
> >>>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
> >>>>>
> >>>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
> >>>>> for dpt")
> >>>>> Cc: # v6.0+
> >>>>> Cc: Ville Syrjälä
> >>>>> Cc: Tvrtko Ursulin
> >>>>> Suggested-by: Chris Wilson
> >>>>> Signed-off-by: Fei Yang
> >>>>> Signed-off-by: Radhakrishna Sripada
> >>>>> ---
> >>>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> >>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> index 7c5fddb203ba..fbfd8f959f17 100644
> >>>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
> >> i915_address_space *vm)
> >>>>>i915_vma_get(vma);
> >>>>>}
> >>>>>
> >>>>> +dpt->obj->mm.dirty = true;
> >>>>> +
> >>>>>atomic_dec(>gpu_error.pending_fb_pin);
> >>>>>intel_runtime_pm_put(>runtime_pm, wakeref);
> >>>>>
> >>>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> >>>>>dpt_obj = i915_gem_object_create_stolen(i915, size);
> >>>>>if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> >>>>>drm_dbg_kms(>drm, "Allocating dpt from smem\n");
> >>>>> -dpt_obj = i915_gem_object_create_internal(i915, size);
> >>>>> +dpt_obj = i915_gem_object_create_shmem(i915, size);
> >>>>>}
> >>>>>if (IS_ERR(dpt_obj))
> >>>>>return ERR_CAST(dpt_obj);
> >>>>
> >>>> Okay I think I get it after some more looking at the DPT code paths.
> >>>> Problem seems pretty clear - page tables are stored in dpt_obj and so
> >>>> are lost when backing store is discarded.
> >>>>
> >>>> Changing to shmem object indeed looks the easiest option.
> >>>>
> >>>> Some related thoughts:
> >>>>
> >>>> 1)
> >>>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> >>>> Could you investigate please? On a glance their job was to restore the
> >>>> PTEs which would be lost from internal objects backing storage. With
> >>>> shmem objects that content should be preserved.
> >>>
> >>> intel_dpt_suspend is "suspending" the whole VM where, not o
Re: [Intel-gfx] [PATCH] drm/i915: Use the i915_vma_flush_writes helper
> -Original Message-
> From: dri-devel On Behalf Of Tvrtko
> Ursulin
> Sent: Friday, July 21, 2023 6:08 AM
> To: Intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Ursulin, Tvrtko
> Subject: [PATCH] drm/i915: Use the i915_vma_flush_writes helper
>
> From: Tvrtko Ursulin
>
> We can use the existing helper in flush_write_domain() and save some lines
> of code.
>
LGTM,
Radhakrishna Sripada
--Radhakrishna(RK) Sripada
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index dfaaa8b66ac3..ffddec1d2a76 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -68,10 +68,8 @@ flush_write_domain(struct drm_i915_gem_object *obj,
> unsigned int flush_domains)
> switch (obj->write_domain) {
> case I915_GEM_DOMAIN_GTT:
> spin_lock(>vma.lock);
> - for_each_ggtt_vma(vma, obj) {
> - if (i915_vma_unset_ggtt_write(vma))
> - intel_gt_flush_ggtt_writes(vma->vm->gt);
> - }
> + for_each_ggtt_vma(vma, obj)
> + i915_vma_flush_writes(vma);
> spin_unlock(>vma.lock);
>
> i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> --
> 2.39.2
Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
Hi Tvrtko,
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, July 20, 2023 2:17 AM
> To: Yang, Fei ; Sripada, Radhakrishna
> ; intel-gfx@lists.freedesktop.org
> Cc: sta...@vger.kernel.org; Ville Syrjälä ;
> Wilson,
> Chris P
> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>
>
> On 19/07/2023 21:53, Yang, Fei wrote:
> >> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> >>> Dpt objects that are created from internal get evicted when there is
> >>> memory pressure and do not get restored when pinned during scanout.
> >>> The pinned page table entries look corrupted and programming the
> >>> display engine with the incorrect pte's result in DE throwing pipe faults.
> >>>
> >>> Create DPT objects from shmem and mark the object as dirty when
> >>> pinning so that the object is restored when shrinker evicts an unpinned
> buffer object.
> >>>
> >>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
> >>>
> >>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
> >>> for dpt")
> >>> Cc: # v6.0+
> >>> Cc: Ville Syrjälä
> >>> Cc: Tvrtko Ursulin
> >>> Suggested-by: Chris Wilson
> >>> Signed-off-by: Fei Yang
> >>> Signed-off-by: Radhakrishna Sripada
> >>> ---
> >>>drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> >>>1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> index 7c5fddb203ba..fbfd8f959f17 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
> i915_address_space *vm)
> >>> i915_vma_get(vma);
> >>> }
> >>>
> >>> +dpt->obj->mm.dirty = true;
> >>> +
> >>> atomic_dec(>gpu_error.pending_fb_pin);
> >>> intel_runtime_pm_put(>runtime_pm, wakeref);
> >>>
> >>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> >>> dpt_obj = i915_gem_object_create_stolen(i915, size);
> >>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> >>> drm_dbg_kms(>drm, "Allocating dpt from smem\n");
> >>> -dpt_obj = i915_gem_object_create_internal(i915, size);
> >>> +dpt_obj = i915_gem_object_create_shmem(i915, size);
> >>> }
> >>> if (IS_ERR(dpt_obj))
> >>> return ERR_CAST(dpt_obj);
> >>
> >> Okay I think I get it after some more looking at the DPT code paths.
> >> Problem seems pretty clear - page tables are stored in dpt_obj and so
> >> are lost when backing store is discarded.
> >>
> >> Changing to shmem object indeed looks the easiest option.
> >>
> >> Some related thoughts:
> >>
> >> 1)
> >> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> >> Could you investigate please? On a glance their job was to restore the
> >> PTEs which would be lost from internal objects backing storage. With
> >> shmem objects that content should be preserved.
> >
> > intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
> > objects are mapped into, but also the framebuffer objects. I don't have
> > much knowledge on how the framebuffer objects are managed, but the
> suspend
> > resume path still look necessary to me, unless the content of these
> > framebuffer objects are also preserved.
>
> I don't think it has anything to do with fb content, but you are correct
> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
> mapping for DPT FBs across system suspend/resume") reminds me backing
> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
> Even though with this patch internal is out of the picture, stolen
> remains and so the issue of losing the page table content remains.
> Perhaps resume could be optimised to only restore PTEs when VM page
> tables are backed by stolen which may win some suspend/resume speed on
> some platforms.
I will have to look into how suspend resume will change with the current flow
as you said it can be looked in a later patch.
>
> Regards,
>
> T
Re: [Intel-gfx] [PATCH] drm/i915/dpt: Use shmem for dpt objects
Hi Tvrtko,
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Tuesday, July 18, 2023 3:08 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dpt: Use shmem for dpt objects
>
>
> On 18/07/2023 06:33, Radhakrishna Sripada wrote:
> > Dpt objects that are created from internal get evicted when there is
> > memory pressure and do not get restored when pinned during scanout. The
> > pinned page table entries look corrupted and programming the display
> > engine with the incorrect pte's result in DE throwing pipe faults.
> >
> > Create DPT objects from shmem and mark the object as dirty when pinning so
> > that the object is restored when shrinker evicts an unpinned buffer object.
> >
> > Cc: Ville Syrjälä
>
> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
> Cc: # v6.0+
>
> Not sure which platforms it actually applies so just mentioning to pick the
> right
> one.
Sure will add the above ones.
>
> > Suggested-by: Chris Wilson
> > Signed-off-by: Fei Yang
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/display/intel_dpt.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> b/drivers/gpu/drm/i915/display/intel_dpt.c
> > index 7c5fddb203ba..a57d18550a46 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> > @@ -166,6 +166,9 @@ struct i915_vma *intel_dpt_pin(struct
> i915_address_space *vm)
> > i915_vma_get(vma);
> > }
> >
> > + if (i915_gem_object_is_shmem(dpt->obj))
> > + dpt->obj->cache_dirty = true;
>
> GPU writes to this object behind the covers or what is supposed to be the
> purpose of this?
This is to make sure that pages when writing/obtained back from swap do not
loose its contents. dpt->obj->mm.dirty = true is also achieving the same result.
Without either of the above changes, we get the following corrupt pte's.
Speaking with Chris it was suggested to unconditionally mark dpt->ob->mm.dirty
= true
so that contents of the pages do not get lost during swap out/swap in.
[ 6991.405300] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0xf200, Pte[0]: 0x20f201
[ 6991.405803] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0x0, Pte[8696]: 0x21
[ 6991.406527] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0x1000, Pte[8697]: 0x201001
[ 6991.406816] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0x2000, Pte[8698]: 0x202001
[ 6991.407071] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0x3000, Pte[8699]: 0x203001
[ 6991.407301] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0x4000, Pte[8700]: 0x204001
[ 6991.407518] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0x5000, Pte[8701]: 0x205001
[ 6991.407727] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0x6000, Pte[8702]: 0x206001
[ 6991.407939] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[88814582b800] Addr: 0x7000, Pte[8703]: 0x207001
[ 6991.408329] i915 :00:02.0: [drm:intel_power_well_enable [i915]] enabling
DC_off
[ 6991.409254] i915 :00:02.0: [drm:gen9_set_dc_state.part.0 [i915]] Setting
DC state from 02 to 00
[ 6991.441831] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[888145828800] Addr: 0xf600, Pte[0]: 0x20f601
[ 6991.442316] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[888145828800] Addr: 0x0, Pte[8696]: 0x21
[ 6991.442561] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[888145828800] Addr: 0x1000, Pte[8697]: 0x201001
[ 6991.442780] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[888145828800] Addr: 0x2000, Pte[8698]: 0x202001
[ 6991.443043] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[888145828800] Addr: 0x3000, Pte[8699]: 0x203001
[ 6991.443271] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[888145828800] Addr: 0x4000, Pte[8700]: 0x204001
[ 6991.443480] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[888145828800] Addr: 0x5000, Pte[8701]: 0x205001
[ 6991.443693] i915 :00:02.0: [drm:intel_plane_pin_fb [i915]] DPT
OBJ[888145828800] Addr: 0x6000, Pte[8702]: 0x206001
[ 6991.443906] i915 :00:02.0: [drm:intel_p
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Make intel_crtc_get_vblank_counter use no trace hw reads
Hi Lucas,
> -Original Message-
> From: De Marchi, Lucas
> Sent: Thursday, June 22, 2023 12:41 PM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org; Maarten Lankhorst
>
> Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915: Make
> intel_crtc_get_vblank_counter use no trace hw reads
>
> On Tue, Jun 13, 2023 at 02:52:44PM -0700, Radhakrishna Sripada wrote:
> >intel_crtc_get_vblank_counter is used in many places in the display
> >tracing infrastructure. For a clean execution of the tracing assignment,
> >ensure that any necessary HW reads would not further trigger another trace,
> >to prevent nesting of trace events.
>
>
> it's not clear what "nesting" means in this patch series. For me
> "nesting" would be if in the middle of a trace event it triggered
> another trace event. Given our current infra, I don't see how that
> would be possible.
Intel_crtc_get_vblank_counter/intel_get_crtc_scanline is used at many of the
trace events defined in intel_display_trace.h like intel_pipe_{en,dis}able,
intel_pipe_crc
during the assign phase to capture the current vblank and scanline values.
However those
functions indeed use traceable versions of register reads making a nested trace
call.
kworker/u29:0-153 [007] 402.314951: kernel_stack:=>
trace_event_raw_event_i915_reg_rw
=> __intel_get_crtc_scanline
=> intel_get_crtc_scanline
=> trace_event_raw_event_intel_plane_update_noarm
=> intel_plane_update_noarm
=> intel_crtc_planes_update_noarm
=> intel_update_crtc
=> skl_commit_modeset_enables
>
> Do you mean that certain register accesses are being reported twice
> since they are being recorded in 2 different layers like intel_de and
> intel_uncore? If so, can you add in the commit message what is the call
> chain you're seeing? The indirections in intel_de_read_fw() are not so
> easy to follow, but from a quick look I don't see that happening here.
I haven't observed those style of reporting twice.
--Radhakrishna(RK) Sripada
>
> intel_de_read_fw()
>intel_uncore_read_fw()
> __raw_uncore_read32() <-- no trace here
>trace_i915_reg_rw()
>
> What makes intel_de_read_fw() call special in this intel_vblank.c that
> is not the case in all the hundred other places this function is called?
>
> The trace_i915_reg_rw() in intel_de_read_fw() was added exactly because
> __raw_uncore_read32() doesn't trace.
>
> In xe, we should probably override the intel_de_read_fw() with a
> xe-specific function that just leaves the trace out, delegated to
> xe_mmio().
>
>
> Btw, see the comment on top of intel_uncore_read_fw() that nobody reads
> and calls to those "raw" accessors are added, making the i915_reg_rw
> trace almost useless.
>
> $ git grep intel_uncore_read_fw | wc -l
> 65
>
> The _fw() suffix was meant as: you first take the forcewake, then
> you access a bunch of registers, then release the forcewake. The
> non-trace is a bad side effect with no clue on the name of the function,
> just a comment on top of it.
>
> Lucas De Marchi
>
>
> >
> >Suggested-by: Maarten Lankhorst
> >Signed-off-by: Radhakrishna Sripada
> >---
> > drivers/gpu/drm/i915/display/intel_vblank.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c
> b/drivers/gpu/drm/i915/display/intel_vblank.c
> >index f5659ebd08eb..55f3389fa220 100644
> >--- a/drivers/gpu/drm/i915/display/intel_vblank.c
> >+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
> >@@ -103,7 +103,7 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
> > * we get a low value that's stable across two reads of the high
> > * register.
> > */
> >-frame = intel_de_read64_2x32(dev_priv, PIPEFRAMEPIXEL(pipe),
> PIPEFRAME(pipe));
> >+frame = intel_de_read64_2x32_notrace(dev_priv,
> PIPEFRAMEPIXEL(pipe), PIPEFRAME(pipe));
> >
> > pixel = frame & PIPE_PIXEL_MASK;
> > frame = (frame >> PIPE_FRAME_LOW_SHIFT) & 0xff;
> >@@ -125,7 +125,7 @@ u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
> > if (!vblank->max_vblank_count)
> > return 0;
> >
> >-return intel_de_read(dev_priv, PIPE_FRMCOUNT_G4X(pipe));
> >+return intel_de_read_notrace(dev_priv, PIPE_FRMCOUNT_G4X(pipe));
> > }
> >
> > static u32 intel_crtc_scanlines_since_frame_timestamp(struct intel_crtc
> > *crtc)
> >@@ -324,7 +324,8 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc
> *_crtc,
> > *
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Skip using vbt hdmi_level_shifter selection on MTL
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, June 21, 2023 12:32 AM
> To: Sripada, Radhakrishna ; Taylor, Clinton A
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Skip using vbt
> hdmi_level_shifter
> selection on MTL
>
> On Tue, 20 Jun 2023, "Sripada, Radhakrishna"
> wrote:
> > Merged. Thank you for the review.
>
> Where are the CI results?
>
> Please never merge patches without CI results.
Apologies Jani. Overlooked the green as CI results as the patch was sent 3 days
ago. Let me trigger a fresh CI run.
Will keep this in mind for future.
--Radhakrishna(RK) Sripada
>
> BR,
> Jani.
>
> >
> > --Radhakrishna(RK) Sripada
> >
> >> -Original Message-
> >> From: Taylor, Clinton A
> >> Sent: Tuesday, June 20, 2023 2:10 PM
> >> To: Sripada, Radhakrishna ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Lee, Shawn C ; Almahallawy, Khaled
> >>
> >> Subject: Re: [PATCH] drm/i915/mtl: Skip using vbt hdmi_level_shifter
> selection
> >> on MTL
> >>
> >> On Fri, 2023-06-16 at 14:00 -0700, Radhakrishna Sripada wrote:
> >> > The hdmi_level_shifter part of General Bytes definition in VBT, which was
> >> > used for choosing different levels on earlier platforms is now a hidden
> >> > optin and shows the default value of 0. The level shifter is now to be
> >> > deduced from hdmi_default_entry in intel_ddi_buf_trans for each phy.
> >> >
> >> > Skip providing the default hw provided value to force driver to choose
> >> > hdmi
> >> > default entry.
> >> >
> >> > Bspec: 20124
> >> > Cc: Khaled Almahallawy
> >> > Cc: Lee Shawn C
> >> > Cc: Clint Taylor
> >> > Signed-off-by: Radhakrishna Sripada
> >> > ---
> >> > drivers/gpu/drm/i915/display/intel_bios.c | 3 ++-
> >> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> >> > b/drivers/gpu/drm/i915/display/intel_bios.c
> >> > index 34a397adbd6b..4b9bf76e137d 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> >> > @@ -2615,7 +2615,8 @@ intel_bios_encoder_is_lspcon(const struct
> >> intel_bios_encoder_data
> >> > *devdata)
> >> > /* This is an index in the HDMI/DVI DDI buffer translation table, or -1
> >> > */
> >> > int intel_bios_hdmi_level_shift(const struct intel_bios_encoder_data
> >> *devdata)
> >> > {
> >> > -if (!devdata || devdata->i915->display.vbt.version < 158)
> >> > +if (!devdata || devdata->i915->display.vbt.version < 158 ||
> >> > +DISPLAY_VER(devdata->i915) >= 14)
> >> > return -1;
> >> >
> >> Reviewed-by: Clint Taylor
> >>
> >> -Clint
> >>
> >> > return devdata->child.hdmi_level_shifter_value;
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [v4] drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4
Merged. Thank you for the patch and review.
--Radhakrishna(RK) Sripada
> -Original Message-
> From: Lee, Shawn C
> Sent: Thursday, June 8, 2023 5:21 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lee, Shawn C ; Kahola, Mika
> ; Taylor, Clinton A ;
> Sripada, Radhakrishna ; Shankar, Uma
>
> Subject: [v4] drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4
>
> Add vswing table to support DP 1.4 for C20 phy.
>
> v2: rename mtl_c10_trans
> v3: add default_entry for mtl_c20_trans_dp14
> v4: rename mtl_cx0_trans_dp14
>
> Bspec: 74104
> Signed-off-by: Lee Shawn C
> Cc: Mika Kahola
> Cc: Clint Taylor
> Cc: Radhakrishna Sripada
> Cc: Uma Shankar
> Reviewed-by: Mika Kahola
> Reviewed-by: Radhakrishna Sripada
> ---
> .../drm/i915/display/intel_ddi_buf_trans.c| 26 +--
> 1 file changed, 24 insertions(+), 2 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..8d2932d079cf 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1049,12 +1049,26 @@ static const union intel_ddi_buf_trans_entry
> _mtl_c10_trans_dp14[] = {
> { .snps = { 62, 0, 0 } }, /* preset 9 */
> };
>
> -static const struct intel_ddi_buf_trans mtl_cx0_trans = {
> +static const struct intel_ddi_buf_trans mtl_c10_trans_dp14 = {
> .entries = _mtl_c10_trans_dp14,
> .num_entries = ARRAY_SIZE(_mtl_c10_trans_dp14),
> .hdmi_default_entry = ARRAY_SIZE(_mtl_c10_trans_dp14) - 1,
> };
>
> +/* DP1.4 */
> +static const union intel_ddi_buf_trans_entry _mtl_c20_trans_dp14[] = {
> + { .snps = { 20, 0, 0 } }, /* preset 0 */
> + { .snps = { 24, 0, 4 } }, /* preset 1 */
> + { .snps = { 30, 0, 9 } }, /* preset 2 */
> + { .snps = { 34, 0, 14 } }, /* preset 3 */
> + { .snps = { 29, 0, 0 } }, /* preset 4 */
> + { .snps = { 34, 0, 5 } }, /* preset 5 */
> + { .snps = { 38, 0, 10 } }, /* preset 6 */
> + { .snps = { 36, 0, 0 } }, /* preset 7 */
> + { .snps = { 40, 0, 6 } }, /* preset 8 */
> + { .snps = { 48, 0, 0 } }, /* preset 9 */
> +};
> +
> /* DP2.0 */
> static const union intel_ddi_buf_trans_entry _mtl_c20_trans_uhbr[] = {
> { .snps = { 48, 0, 0 } }, /* preset 0 */
> @@ -1090,6 +1104,12 @@ static const struct intel_ddi_buf_trans
> mtl_c20_trans_hdmi = {
> .hdmi_default_entry = 0,
> };
>
> +static const struct intel_ddi_buf_trans mtl_c20_trans_dp14 = {
> + .entries = _mtl_c20_trans_dp14,
> + .num_entries = ARRAY_SIZE(_mtl_c20_trans_dp14),
> + .hdmi_default_entry = ARRAY_SIZE(_mtl_c20_trans_dp14) - 1,
> +};
> +
> static const struct intel_ddi_buf_trans mtl_c20_trans_uhbr = {
> .entries = _mtl_c20_trans_uhbr,
> .num_entries = ARRAY_SIZE(_mtl_c20_trans_uhbr),
> @@ -1678,8 +1698,10 @@ mtl_get_cx0_buf_trans(struct intel_encoder
> *encoder,
> return intel_get_buf_trans(_c20_trans_uhbr, n_entries);
> else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
> !(intel_is_c10phy(i915, phy)))
> return intel_get_buf_trans(_c20_trans_hdmi, n_entries);
> + else if (!intel_is_c10phy(i915, phy))
> + return intel_get_buf_trans(_c20_trans_dp14, n_entries);
> else
> - return intel_get_buf_trans(_cx0_trans, n_entries);
> + return intel_get_buf_trans(_c10_trans_dp14, n_entries);
> }
>
> void intel_ddi_buf_trans_init(struct intel_encoder *encoder)
> --
> 2.17.1
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix SSC selection for MPLLA
Merged. With slight change to commit message to silence checkpatch warning.
Thank you for the review.
--Radhakrishna(RK) Sripada
> -Original Message-
> From: Kahola, Mika
> Sent: Friday, June 16, 2023 12:05 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: Taylor, Clinton A ; Almahallawy, Khaled
> ; Murthy, Arun R
> Subject: RE: [PATCH] drm/i915/mtl: Fix SSC selection for MPLLA
>
> > -Original Message-
> > From: Sripada, Radhakrishna
> > Sent: Friday, June 16, 2023 7:40 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Sripada, Radhakrishna ; Kahola, Mika
> ; Taylor, Clinton A
> > ; Almahallawy, Khaled
> ; Murthy, Arun R
> >
> > Subject: [PATCH] drm/i915/mtl: Fix SSC selection for MPLLA
> >
> > Driver does not clear the default SSC for MPLLA. This causes link training
> failure when trying to use 10G and 20G rates. Fix the
> > behaviour and enable ssc only when we really want.
> >
> > Fixes: 237e7be0bf57 ("drm/i915/mtl: For DP2.0 10G and 20G rates use
> MPLLA")
> > Cc: Mika Kahola
> > Cc: Clint Taylor
> > Cc: Khaled Almahallawy
> > Cc: Arun R Murthy
>
> Reviewed-by: Mika Kahola
>
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index f235df5646ed..1b00ef2c6185 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -2434,7 +2434,8 @@ static void intel_program_port_clock_ctl(struct
> intel_encoder *encoder,
> >
> > intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port),
> > XELPDP_LANE1_PHY_CLOCK_SELECT |
> XELPDP_FORWARD_CLOCK_UNGATE |
> > -XELPDP_DDI_CLOCK_SELECT_MASK |
> XELPDP_SSC_ENABLE_PLLB, val);
> > +XELPDP_DDI_CLOCK_SELECT_MASK |
> XELPDP_SSC_ENABLE_PLLA |
> > +XELPDP_SSC_ENABLE_PLLB, val);
> > }
> >
> > static u32 intel_cx0_get_powerdown_update(u8 lane_mask)
> > --
> > 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Skip using vbt hdmi_level_shifter selection on MTL
Merged. Thank you for the review.
--Radhakrishna(RK) Sripada
> -Original Message-
> From: Taylor, Clinton A
> Sent: Tuesday, June 20, 2023 2:10 PM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: Lee, Shawn C ; Almahallawy, Khaled
>
> Subject: Re: [PATCH] drm/i915/mtl: Skip using vbt hdmi_level_shifter selection
> on MTL
>
> On Fri, 2023-06-16 at 14:00 -0700, Radhakrishna Sripada wrote:
> > The hdmi_level_shifter part of General Bytes definition in VBT, which was
> > used for choosing different levels on earlier platforms is now a hidden
> > optin and shows the default value of 0. The level shifter is now to be
> > deduced from hdmi_default_entry in intel_ddi_buf_trans for each phy.
> >
> > Skip providing the default hw provided value to force driver to choose hdmi
> > default entry.
> >
> > Bspec: 20124
> > Cc: Khaled Almahallawy
> > Cc: Lee Shawn C
> > Cc: Clint Taylor
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/display/intel_bios.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 34a397adbd6b..4b9bf76e137d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -2615,7 +2615,8 @@ intel_bios_encoder_is_lspcon(const struct
> intel_bios_encoder_data
> > *devdata)
> > /* This is an index in the HDMI/DVI DDI buffer translation table, or -1 */
> > int intel_bios_hdmi_level_shift(const struct intel_bios_encoder_data
> *devdata)
> > {
> > - if (!devdata || devdata->i915->display.vbt.version < 158)
> > + if (!devdata || devdata->i915->display.vbt.version < 158 ||
> > + DISPLAY_VER(devdata->i915) >= 14)
> > return -1;
> >
> Reviewed-by: Clint Taylor
>
> -Clint
>
> > return devdata->child.hdmi_level_shifter_value;
Re: [Intel-gfx] [RFC 1/2] drm/xe: Move mmio read/write functions to xe_mmio.c
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, June 13, 2023 7:03 PM
> To: Sripada, Radhakrishna
> Cc: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; De
> Marchi,
> Lucas
> Subject: Re: [RFC 1/2] drm/xe: Move mmio read/write functions to xe_mmio.c
>
> On Tue, Jun 13, 2023 at 05:13:14PM -0700, Radhakrishna Sripada wrote:
> > Move the register read/write apis to xe_mmio.c to prepare for
> > adding tracing infrastructure for the same. Adding tracing support
> > in xe_mmio.h messes with the compilation of the display code.
> >
> > Cc: Lucas De Marchi
> > Cc: Matt Roper
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/xe/xe_mmio.c | 113 ++
> > drivers/gpu/drm/xe/xe_mmio.h | 129 ---
> > 2 files changed, 128 insertions(+), 114 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_mmio.c b/drivers/gpu/drm/xe/xe_mmio.c
> > index 475b14fe4356..70ad1b6a17a0 100644
> > --- a/drivers/gpu/drm/xe/xe_mmio.c
> > +++ b/drivers/gpu/drm/xe/xe_mmio.c
> > @@ -435,6 +435,119 @@ static const struct xe_reg mmio_read_whitelist[] = {
> > RING_TIMESTAMP(RENDER_RING_BASE),
> > };
> >
> > +inline u8 xe_mmio_read8(struct xe_gt *gt, struct xe_reg reg)
>
> We shouldn't have 'inline' on non-static functions in a .c file (and
> generally we don't really want it on static functions either since the
> compiler can generally do a better job of figuring out whether or not
> inlining would be beneficial).
>
Sure Matt. Will do that in next rev.
-Radhakrishna(RK) Sripada
>
> Matt
>
> > +{
> > + struct xe_tile *tile = gt_to_tile(gt);
> > +
> > + if (reg.addr < gt->mmio.adj_limit)
> > + reg.addr += gt->mmio.adj_offset;
> > +
> > + return readb(tile->mmio.regs + reg.addr);
> > +}
> > +
> > +inline void xe_mmio_write32(struct xe_gt *gt,
> > + struct xe_reg reg, u32 val)
> > +{
> > + struct xe_tile *tile = gt_to_tile(gt);
> > +
> > + if (reg.addr < gt->mmio.adj_limit)
> > + reg.addr += gt->mmio.adj_offset;
> > +
> > + writel(val, tile->mmio.regs + reg.addr);
> > +}
> > +
> > +inline u32 xe_mmio_read32(struct xe_gt *gt, struct xe_reg reg)
> > +{
> > + struct xe_tile *tile = gt_to_tile(gt);
> > +
> > + if (reg.addr < gt->mmio.adj_limit)
> > + reg.addr += gt->mmio.adj_offset;
> > +
> > + return readl(tile->mmio.regs + reg.addr);
> > +}
> > +
> > +inline u32 xe_mmio_rmw32(struct xe_gt *gt, struct xe_reg reg, u32 clr,
> > +u32 set)
> > +{
> > + u32 old, reg_val;
> > +
> > + old = xe_mmio_read32(gt, reg);
> > + reg_val = (old & ~clr) | set;
> > + xe_mmio_write32(gt, reg, reg_val);
> > +
> > + return old;
> > +}
> > +
> > +inline void xe_mmio_write64(struct xe_gt *gt,
> > + struct xe_reg reg, u64 val)
> > +{
> > + struct xe_tile *tile = gt_to_tile(gt);
> > +
> > + if (reg.addr < gt->mmio.adj_limit)
> > + reg.addr += gt->mmio.adj_offset;
> > +
> > + writeq(val, tile->mmio.regs + reg.addr);
> > +}
> > +
> > +inline u64 xe_mmio_read64(struct xe_gt *gt, struct xe_reg reg)
> > +{
> > + struct xe_tile *tile = gt_to_tile(gt);
> > +
> > + if (reg.addr < gt->mmio.adj_limit)
> > + reg.addr += gt->mmio.adj_offset;
> > +
> > + return readq(tile->mmio.regs + reg.addr);
> > +}
> > +
> > +inline int xe_mmio_write32_and_verify(struct xe_gt *gt,
> > + struct xe_reg reg, u32 val,
> > + u32 mask, u32 eval)
> > +{
> > + u32 reg_val;
> > +
> > + xe_mmio_write32(gt, reg, val);
> > + reg_val = xe_mmio_read32(gt, reg);
> > +
> > + return (reg_val & mask) != eval ? -EINVAL : 0;
> > +}
> > +
> > +inline int xe_mmio_wait32(struct xe_gt *gt, struct xe_reg reg, u32 val,
> > + u32 mask, u32 timeout_us, u32 *out_val,
> > + bool atomic)
> > +{
> > + ktime_t cur = ktime_get_raw();
> > + const ktime_t end = ktime_add_us(cur, timeout_us);
> > + int ret = -ETIMEDOUT;
> > + s64 wait = 10;
> > + u32 read;
> > +
> > + for (;;) {
> > + read = xe_mmio_read32(gt, reg);
> > + if ((read & m
Re: [Intel-gfx] [v3] drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4
> -Original Message-
> From: Lee, Shawn C
> Sent: Wednesday, June 7, 2023 11:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lee, Shawn C ; Kahola, Mika
> ; Taylor, Clinton A ;
> Sripada, Radhakrishna ; Shankar, Uma
>
> Subject: [v3] drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4
>
> Add vswing table to support DP 1.4 for C20 phy.
>
> v2: rename mtl_c10_trans
> v3: add default_entry into mtl_c20_trans_dp14
>
> Bspec: 74104
> Signed-off-by: Lee Shawn C
> Cc: Mika Kahola
> Cc: Clint Taylor
> Cc: Radhakrishna Sripada
> Cc: Uma Shankar
> Reviewed-by: Mika Kahola
> Reviewed-by: Radhakrishna Sripada
> ---
> .../drm/i915/display/intel_ddi_buf_trans.c| 26 +--
> 1 file changed, 24 insertions(+), 2 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..d7301f13c5cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1049,12 +1049,26 @@ static const union intel_ddi_buf_trans_entry
> _mtl_c10_trans_dp14[] = {
> { .snps = { 62, 0, 0 } }, /* preset 9 */
> };
>
> -static const struct intel_ddi_buf_trans mtl_cx0_trans = {
> +static const struct intel_ddi_buf_trans mtl_cx0_trans_dp14 = {
Kindly rename this to mtl_c10_trans_dp14. Cx0 should not be used if it is not
Being used by both c10 and c20 phys.
--Radhakrishna(RK) Sripada
> .entries = _mtl_c10_trans_dp14,
> .num_entries = ARRAY_SIZE(_mtl_c10_trans_dp14),
> .hdmi_default_entry = ARRAY_SIZE(_mtl_c10_trans_dp14) - 1,
> };
>
> +/* DP1.4 */
> +static const union intel_ddi_buf_trans_entry _mtl_c20_trans_dp14[] = {
> + { .snps = { 20, 0, 0 } }, /* preset 0 */
> + { .snps = { 24, 0, 4 } }, /* preset 1 */
> + { .snps = { 30, 0, 9 } }, /* preset 2 */
> + { .snps = { 34, 0, 14 } }, /* preset 3 */
> + { .snps = { 29, 0, 0 } }, /* preset 4 */
> + { .snps = { 34, 0, 5 } }, /* preset 5 */
> + { .snps = { 38, 0, 10 } }, /* preset 6 */
> + { .snps = { 36, 0, 0 } }, /* preset 7 */
> + { .snps = { 40, 0, 6 } }, /* preset 8 */
> + { .snps = { 48, 0, 0 } }, /* preset 9 */
> +};
> +
> /* DP2.0 */
> static const union intel_ddi_buf_trans_entry _mtl_c20_trans_uhbr[] = {
> { .snps = { 48, 0, 0 } }, /* preset 0 */
> @@ -1090,6 +1104,12 @@ static const struct intel_ddi_buf_trans
> mtl_c20_trans_hdmi = {
> .hdmi_default_entry = 0,
> };
>
> +static const struct intel_ddi_buf_trans mtl_c20_trans_dp14 = {
> + .entries = _mtl_c20_trans_dp14,
> + .num_entries = ARRAY_SIZE(_mtl_c20_trans_dp14),
> + .hdmi_default_entry = ARRAY_SIZE(_mtl_c20_trans_dp14) - 1,
> +};
> +
> static const struct intel_ddi_buf_trans mtl_c20_trans_uhbr = {
> .entries = _mtl_c20_trans_uhbr,
> .num_entries = ARRAY_SIZE(_mtl_c20_trans_uhbr),
> @@ -1678,8 +1698,10 @@ mtl_get_cx0_buf_trans(struct intel_encoder
> *encoder,
> return intel_get_buf_trans(_c20_trans_uhbr, n_entries);
> else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
> !(intel_is_c10phy(i915, phy)))
> return intel_get_buf_trans(_c20_trans_hdmi, n_entries);
> + else if (!intel_is_c10phy(i915, phy))
> + return intel_get_buf_trans(_c20_trans_dp14, n_entries);
> else
> - return intel_get_buf_trans(_cx0_trans, n_entries);
> + return intel_get_buf_trans(_cx0_trans_dp14, n_entries);
> }
>
> void intel_ddi_buf_trans_init(struct intel_encoder *encoder)
> --
> 2.17.1
Re: [Intel-gfx] [v2] drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4
Hi Shawn,
> -Original Message-
> From: Lee, Shawn C
> Sent: Wednesday, June 7, 2023 9:10 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lee, Shawn C ; Kahola, Mika
> ; Taylor, Clinton A ;
> Sripada, Radhakrishna ; Shankar, Uma
>
> Subject: [v2] drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4
>
> Add vswing table to support DP 1.4 for C20 phy.
>
> v2: rename mtl_c10_trans
>
> Bspec: 74104
> Signed-off-by: Lee Shawn C
> Cc: Mika Kahola
> Cc: Clint Taylor
> Cc: Radhakrishna Sripada
> Cc: Uma Shankar
> Reviewed-by: Mika Kahola
> Reviewed-by: Radhakrishna Sripada
> ---
> .../drm/i915/display/intel_ddi_buf_trans.c| 25 +--
> 1 file changed, 23 insertions(+), 2 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..a6276a9ba61c 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1049,12 +1049,26 @@ static const union intel_ddi_buf_trans_entry
> _mtl_c10_trans_dp14[] = {
> { .snps = { 62, 0, 0 } }, /* preset 9 */
> };
>
> -static const struct intel_ddi_buf_trans mtl_cx0_trans = {
> +static const struct intel_ddi_buf_trans mtl_cx0_trans_dp14 = {
This should be renamed to mtl_c10_trans_dp14 as this no longer applies to c20
phy.
Only if it applies to both c10 and c20 phys, should it be used as cx0 phy.
> .entries = _mtl_c10_trans_dp14,
> .num_entries = ARRAY_SIZE(_mtl_c10_trans_dp14),
> .hdmi_default_entry = ARRAY_SIZE(_mtl_c10_trans_dp14) - 1,
> };
>
> +/* DP1.4 */
> +static const union intel_ddi_buf_trans_entry _mtl_c20_trans_dp14[] = {
> + { .snps = { 20, 0, 0 } }, /* preset 0 */
> + { .snps = { 24, 0, 4 } }, /* preset 1 */
> + { .snps = { 30, 0, 9 } }, /* preset 2 */
> + { .snps = { 34, 0, 14 } }, /* preset 3 */
> + { .snps = { 29, 0, 0 } }, /* preset 4 */
> + { .snps = { 34, 0, 5 } }, /* preset 5 */
> + { .snps = { 38, 0, 10 } }, /* preset 6 */
> + { .snps = { 36, 0, 0 } }, /* preset 7 */
> + { .snps = { 40, 0, 6 } }, /* preset 8 */
> + { .snps = { 48, 0, 0 } }, /* preset 9 */
> +};
> +
> /* DP2.0 */
> static const union intel_ddi_buf_trans_entry _mtl_c20_trans_uhbr[] = {
> { .snps = { 48, 0, 0 } }, /* preset 0 */
> @@ -1090,6 +1104,11 @@ static const struct intel_ddi_buf_trans
> mtl_c20_trans_hdmi = {
> .hdmi_default_entry = 0,
> };
>
> +static const struct intel_ddi_buf_trans mtl_c20_trans_dp14 = {
> + .entries = _mtl_c20_trans_dp14,
> + .num_entries = ARRAY_SIZE(_mtl_c20_trans_dp14),
Just like in c10 case add
.hdmi_default_entry = ARRAY_SIZE(_mtl_c20_trans_dp14) - 1,
--Radhakrishna(RK) Sripada
> +};
> +
> static const struct intel_ddi_buf_trans mtl_c20_trans_uhbr = {
> .entries = _mtl_c20_trans_uhbr,
> .num_entries = ARRAY_SIZE(_mtl_c20_trans_uhbr),
> @@ -1678,8 +1697,10 @@ mtl_get_cx0_buf_trans(struct intel_encoder
> *encoder,
> return intel_get_buf_trans(_c20_trans_uhbr, n_entries);
> else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
> !(intel_is_c10phy(i915, phy)))
> return intel_get_buf_trans(_c20_trans_hdmi, n_entries);
> + else if (!intel_is_c10phy(i915, phy))
> + return intel_get_buf_trans(_c20_trans_dp14, n_entries);
> else
> - return intel_get_buf_trans(_cx0_trans, n_entries);
> + return intel_get_buf_trans(_cx0_trans_dp14, n_entries);
> }
>
> void intel_ddi_buf_trans_init(struct intel_encoder *encoder)
> --
> 2.17.1
Re: [Intel-gfx] [PATCH v15 7/7] drm/i915/mtl: Add support for PM DEMAND
Thank you for the series and the review. Pushed with a minor spelling fix in the comment s/qclck_gc/qclk_gv/ --Radhakrishna(RK) Sripada > -Original Message- > From: Intel-gfx On Behalf Of Vinod > Govindapillai > Sent: Tuesday, June 6, 2023 1:11 PM > To: intel-gfx@lists.freedesktop.org > Cc: jani.saarin...@intel.com > Subject: [Intel-gfx] [PATCH v15 7/7] drm/i915/mtl: Add support for PM DEMAND > > From: Mika Kahola > > MTL introduces a new way to instruct the PUnit with > power and bandwidth requirements of DE. Add the functionality > to program the registers and handle waits using interrupts. > The current wait time for timeouts is programmed for 10 msecs to > factor in the worst case scenarios. Changes made to use REG_BIT > for a register that we touched(GEN8_DE_MISC_IER _MMIO). > > Wa_14016740474 is added which applies to Xe_LPD+ display > > v2: checkpatch warning fixes, simplify program pmdemand part > > v3: update to dbufs and pipes values to pmdemand register(stan) > Removed the macro usage in update_pmdemand_values() > > v4: move the pmdemand_pre_plane_update before cdclk update > pmdemand_needs_update included cdclk params comparisons > pmdemand_state NULL check (Gustavo) > pmdemand.o in sorted order in the makefile (Jani) > update pmdemand misc irq handler loop (Gustavo) > active phys bitmask and programming correction (Gustavo) > > v5: simplify pmdemand_state structure > simplify methods to find active phys and max port clock > Timeout in case of previou pmdemand task pending (Gustavo) > > v6: rebasing > updates to max_ddiclk calculations (Gustavo) > updates to active_phys count method (Gustavo) > > v7: use two separate loop to iterate throug old and new > crtc states to calculate the active phys (Gustavo) > > v8: use uniform function names (Gustavo) > > v9: For phys change iterate through connectors (Imre) > Look for change in phys for pmdemand update (Gustavo, Imre) > Some more stlying changes (Imre) > Update pmdemand state during HW readout/sanitize (Imre) > > v10: Fix CI checkpatch warnings > > v11: use correct pmdemand object pointer during hw readout, > simplify the check for phys need update (Gustavo) > > v12: Handle possible non serialize cases (Imre) > Initialise also pmdemand params HW readout (Imre) > Update active phys mask during sanitize calls (Imre) > Check TC/encoder changes to limit connector update (Imre) > > v13: Check display version before accessing pmdemand functions > > v14: Move is_serialized to intel_global_state.c > simplify update params and other stlying issues (Imre) > > Bspec: 66451, 64636, 64602, 64603 > Cc: Matt Atwood > Cc: Matt Roper > Cc: Lucas De Marchi > Cc: Gustavo Sousa > Signed-off-by: José Roberto de Souza > Signed-off-by: Radhakrishna Sripada > Signed-off-by: Gustavo Sousa > Signed-off-by: Mika Kahola > Signed-off-by: Vinod Govindapillai > Reviewed-by: Stanislav Lisovskiy #v4 > Acked-by: Gustavo Sousa #v11 > Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/display/intel_display.c | 14 + > .../gpu/drm/i915/display/intel_display_core.h | 9 + > .../drm/i915/display/intel_display_driver.c | 7 + > .../gpu/drm/i915/display/intel_display_irq.c | 23 +- > .../drm/i915/display/intel_display_power.c| 14 +- > .../gpu/drm/i915/display/intel_global_state.c | 12 + > .../gpu/drm/i915/display/intel_global_state.h | 2 + > .../drm/i915/display/intel_modeset_setup.c| 32 + > drivers/gpu/drm/i915/display/intel_pmdemand.c | 620 ++ > drivers/gpu/drm/i915/display/intel_pmdemand.h | 67 ++ > drivers/gpu/drm/i915/i915_reg.h | 26 +- > 12 files changed, 821 insertions(+), 6 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.c > create mode 100644 drivers/gpu/drm/i915/display/intel_pmdemand.h > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 1c9ed4c52760..2cd8de174bf6 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -269,6 +269,7 @@ i915-y += \ > display/intel_pch_display.o \ > display/intel_pch_refclk.o \ > display/intel_plane_initial.o \ > + display/intel_pmdemand.o \ > display/intel_psr.o \ > display/intel_quirks.o \ > display/intel_sprite.o \ > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index f51a55f4e9d0..5cbf5eae2414 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -99,6 +99,7 @@ > #include "intel_pcode.h" > #include "intel_pipe_crc.h" > #include "intel_plane_initial.h" > +#include "intel_pmdemand.h" > #include "intel_pps.h" > #include "intel_psr.h" > #include "intel_sdvo.h" > @@ -6352,6 +6353,10 @@ int intel_atomic_check(struct drm_device *dev, >
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4
Hi Shawn,
> -Original Message-
> From: Lee, Shawn C
> Sent: Tuesday, June 6, 2023 3:43 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lee, Shawn C ; Kahola, Mika
> ; Taylor, Clinton A ;
> Sripada, Radhakrishna ; Shankar, Uma
>
> Subject: [PATCH] drm/i915/mtl: Add new vswing table for C20 phy to support DP
> 1.4
>
> Add vswing table to support DP 1.4 for C20 phy.
>
> Bspec: 74104
> Signed-off-by: Lee Shawn C
> Cc: Mika Kahola
> Cc: Clint Taylor
> Cc: Radhakrishna Sripada
> Cc: Uma Shankar
> ---
> .../drm/i915/display/intel_ddi_buf_trans.c| 21 +++
> 1 file changed, 21 insertions(+)
>
> 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..6a1507515119 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -1055,6 +1055,20 @@ static const struct intel_ddi_buf_trans mtl_cx0_trans
> = {
> .hdmi_default_entry = ARRAY_SIZE(_mtl_c10_trans_dp14) - 1,
> };
>
> +/* DP1.4 */
> +static const union intel_ddi_buf_trans_entry _mtl_c20_trans_dp14[] = {
> + { .snps = { 20, 0, 0 } }, /* preset 0 */
> + { .snps = { 24, 0, 4 } }, /* preset 1 */
> + { .snps = { 30, 0, 9 } }, /* preset 2 */
> + { .snps = { 34, 0, 14 } }, /* preset 3 */
> + { .snps = { 29, 0, 0 } }, /* preset 4 */
> + { .snps = { 34, 0, 5 } }, /* preset 5 */
> + { .snps = { 38, 0, 10 } }, /* preset 6 */
> + { .snps = { 36, 0, 0 } }, /* preset 7 */
> + { .snps = { 40, 0, 6 } }, /* preset 8 */
> + { .snps = { 48, 0, 0 } }, /* preset 9 */
> +};
> +
> /* DP2.0 */
> static const union intel_ddi_buf_trans_entry _mtl_c20_trans_uhbr[] = {
> { .snps = { 48, 0, 0 } }, /* preset 0 */
> @@ -1090,6 +1104,11 @@ static const struct intel_ddi_buf_trans
> mtl_c20_trans_hdmi = {
> .hdmi_default_entry = 0,
> };
>
> +static const struct intel_ddi_buf_trans mtl_c20_trans_dp14 = {
> + .entries = _mtl_c20_trans_dp14,
> + .num_entries = ARRAY_SIZE(_mtl_c20_trans_dp14),
> +};
> +
> static const struct intel_ddi_buf_trans mtl_c20_trans_uhbr = {
> .entries = _mtl_c20_trans_uhbr,
> .num_entries = ARRAY_SIZE(_mtl_c20_trans_uhbr),
> @@ -1678,6 +1697,8 @@ mtl_get_cx0_buf_trans(struct intel_encoder
> *encoder,
> return intel_get_buf_trans(_c20_trans_uhbr, n_entries);
> else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
> !(intel_is_c10phy(i915, phy)))
> return intel_get_buf_trans(_c20_trans_hdmi, n_entries);
> + else if (!intel_is_c10phy(i915, phy))
> + return intel_get_buf_trans(_c20_trans_dp14, n_entries);
> else
> return intel_get_buf_trans(_cx0_trans, n_entries);
Nit: With mtl_c20_trans_dp14, mtl_cx0_trans looses its meaning and needs to be
renamed
As mtl_c10_trans or even better mtl_trans_dp14 for the sake of consistency.
With that,
Reviewed-by: Radhakrishna Sripada
--Radhakrishna(RK) Sripada
> }
> --
> 2.31.1
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix expected reg value for Thunderbolt PLL disabling
Thank you for the patch and review. Merged the patch. - Radhakrishna(RK) Sripada > -Original Message- > From: Intel-gfx On Behalf Of Imre > Deak > Sent: Friday, May 12, 2023 7:12 AM > To: Kahola, Mika > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix expected reg value for > Thunderbolt PLL disabling > > On Fri, May 12, 2023 at 03:00:03PM +0300, Mika Kahola wrote: > > While disabling Thunderbolt PLL, we request PLL to be stopped and > > wait for ACK bit to be cleared. The expected value should be '0' > > instead of '~XELPDP_TBT_CLOCK_ACK' or otherwise we incorrectly > > receive dmesg warn "PHY PLL not unlocked in 10us". > > > > Signed-off-by: Mika Kahola > > Reviewed-by: Imre Deak > > > --- > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > > index d94127e7448b..c64cf6778627 100644 > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > > @@ -2861,9 +2861,7 @@ static void intel_mtl_tbt_pll_disable(struct > intel_encoder *encoder) > > > > /* 3. Poll on PORT_CLOCK_CTL TBT CLOCK Ack == "0". */ > > if (__intel_de_wait_for_register(i915, > XELPDP_PORT_CLOCK_CTL(encoder->port), > > -XELPDP_TBT_CLOCK_ACK, > > -~XELPDP_TBT_CLOCK_ACK, > > -10, 0, NULL)) > > +XELPDP_TBT_CLOCK_ACK, 0, 10, 0, > NULL)) > > drm_warn(>drm, "[ENCODER:%d:%s][%c] PHY PLL not > unlocked after 10us.\n", > > encoder->base.base.id, encoder->base.name, > phy_name(phy)); > > > > -- > > 2.34.1 > >
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/mtl: Add MTL performance tuning changes
Thank you for the reviews. Pushed the patches.
- Radhakrishna Sripada
> -Original Message-
> From: Sousa, Gustavo
> Sent: Wednesday, May 17, 2023 12:27 PM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: Justen, Jordan L ; Sripada, Radhakrishna
> ; Kalvala, Haridhar
> ; Roper, Matthew D
>
> Subject: Re: [PATCH v4 1/2] drm/i915/mtl: Add MTL performance tuning
> changes
>
> Quoting Radhakrishna Sripada (2023-05-16 21:40:45-03:00)
> >MTL reuses the tuning parameters for DG2. Extend the dg2
> >performance tuning parameters to MTL.
> >
> >v2: Add DRAW_WATERMARK tuning parameter.
> >v3: Limit DRAW_WATERMARK tuning to non A0 step.
> >v4: Reorder platform checks.
> >Restrict Blend fill caching optimization to Render GT.
> >
> >Bspec: 68331
> >Cc: Haridhar Kalvala
> >Cc: Matt Roper
> >Cc: Gustavo Sousa
> >Signed-off-by: Radhakrishna Sripada
> >---
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 15 ++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >index 786349e95487..b6d3185cf868 100644
> >--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >@@ -817,6 +817,12 @@ static void mtl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> > {
> > struct drm_i915_private *i915 = engine->i915;
> >
> >+dg2_ctx_gt_tuning_init(engine, wal);
> >+
> >+if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_B0, STEP_FOREVER) ||
> >+IS_MTL_GRAPHICS_STEP(i915, P, STEP_B0, STEP_FOREVER))
> >+wa_add(wal, DRAW_WATERMARK, VERT_WM_VAL, 0x3FF, 0, false);
> >+
>
> I would put those (dg2_ctx_gt_tuning_init() call and DRAW_WATERMARK
> programming) in a separate mtl_ctx_gt_tuning_init() function. That would
> be more consistent with having tuning for context save/restore registers
> in separate functions and makes it easy to see this particular programming of
> DRAW_WATERMARK is a recommended tuning instead of a workaround.
>
> With that,
>
> Reviewed-by: Gustavo Sousa
>
> --
> Gustavo Sousa
>
> > if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
> > /* Wa_14014947963 */
> >@@ -1748,6 +1754,13 @@ xelpmp_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> > */
> > static void gt_tuning_settings(struct intel_gt *gt, struct i915_wa_list
> > *wal)
> > {
> >+if (IS_METEORLAKE(gt->i915)) {
> >+if (gt->type != GT_MEDIA)
> >+wa_mcr_write_or(wal, XEHP_L3SCQREG7,
> BLEND_FILL_CACHING_OPT_DIS);
> >+
> >+wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
> >+}
> >+
> > if (IS_PONTEVECCHIO(gt->i915)) {
> > wa_mcr_write(wal, XEHPC_L3SCRUB,
> > SCRUB_CL_DWNGRADE_SHARED |
> SCRUB_RATE_4B_PER_CLK);
> >@@ -2944,7 +2957,7 @@ static void
> > add_render_compute_tuning_settings(struct drm_i915_private *i915,
> >struct i915_wa_list *wal)
> > {
> >-if (IS_DG2(i915))
> >+if (IS_METEORLAKE(i915) || IS_DG2(i915))
> > wa_mcr_write_clr_set(wal, RT_CTRL, STACKID_CTRL,
> STACKID_CTRL_512);
> >
> > /*
> >--
> >2.34.1
> >
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL A-step
Hi Matt, > -Original Message- > From: Roper, Matthew D > Sent: Monday, May 15, 2023 10:28 AM > To: Sripada, Radhakrishna > Cc: Sousa, Gustavo ; intel- > g...@lists.freedesktop.org; Justen, Jordan L ; > Kalvala, Haridhar > Subject: Re: [PATCH v2 1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL A- > step > > On Mon, May 15, 2023 at 08:42:25AM -0700, Sripada, Radhakrishna wrote: > > Hi Gustavo, > > > > > -Original Message- > > > From: Sousa, Gustavo > > > Sent: Monday, May 15, 2023 7:45 AM > > > To: Sripada, Radhakrishna ; intel- > > > g...@lists.freedesktop.org > > > Cc: Justen, Jordan L ; Sripada, Radhakrishna > > > ; Kalvala, Haridhar > > > ; Roper, Matthew D > > > > > > Subject: Re: [PATCH v2 1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL > A- > > > step > > > > > > Quoting Radhakrishna Sripada (2023-05-12 23:14:37) > > > >The dg2 workaround which is used for performance tuning > > > >is needed for Meteorlake A-step. > > > > > > > >v2: Limit the WA for A-step > > > > > > I think what Matt meant in the review for v1 was that this commit should > > > be rather about the tuning setting rather than the workaround itself. As > > > such, maybe we should change the commit message so that it focus on the > > > recommended tuning setting, i.e., instead of "Extend Wa_16014892111 to > > > MTL A-step" as subject, we should write something like "Apply > > > recommended tuning setting for ..." and give details. > > > > > > That said, since we are focusing on the tuning settings here, I guess > > > this could be squashed with the second patch and we could add a note > > > about DRAW_WATERMARK needing Wa_16014892111 for A steps of MTL. > > > > There are 2 aspects wrt. DRAW_WATERMARK. One that is a workaround > > which is applied on each context switch and is only applicable for DG2 > > and MTL-A step which is what this patch does. > > So just to be clear --- the workaround doesn't directly ask us to do > anything specific with DRAW_WATERMARK. What the workaround says is that > *if* we wind up needing to change the value of DRAW_WATERMARK away from > the hardware default, then we need to handle the save/restore on each > context switch ourselves since the hardware doesn't process this > register properly on context switch and will lose its value. > > It turns out that MTL has a tuning setting that suggests changing > DRAW_WATERMARK to a non-default value. Since the tuning setting is > constant (i.e., it doesn't change at runtime based on other factors), we > can ignore the "save" part of the workaround and just hardcode the > "restore" part to the value specified by the tuning setting. But what > we're programming here is still the tuning setting, it's just that the > way we implement the tuning is adjusted by the workaround's guidance. > > It might make sense to swap the order of these patches --- make the > first patch add the tuning setting (in the normal manner) for all > steppings not impacted by the workaround. Then come back and apply the > tuning setting in the special way on the A-step hardware to satisfy the > guidance of Wa_16014892111. Or maybe it's simpler to just ignore the > tuning setting on A-step entirely; that's a pre-production stepping of > the platform, so it's not really going to get used for performance work > anyway. If we don't bother programming the tuning on A-step, then we > also don't need to worry about the workaround either. Thank you for the explanation. I was inclined to drop the WA but we do have B-step parts in CI which have A-step GT hence trying to keep this around. I resend the patches swapping the order and adding better explanation. - Radhakrishna Sripada > > > Matt > > > > > The other is the tuning parameter setting which is applicable for all > > of MTL which is a onetime configuration Handled by the next patch > > during ctx_workarounds_init. > > > > - Radhakrishna Sripada > > > > > > > > > > -- > > > Gustavo Sousa > > > > > > > > > > >Bspec: 68331 > > > >Cc: Haridhar Kalvala > > > >Cc: Matt Roper > > > >Cc: Gustavo Sousa > > > >Signed-off-by: Radhakrishna Sripada > > > >--- > > > > drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > >diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c > > > b/drivers/g
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/mtl: Add MTL performance tuning changes
Hi Haridar/Gustavo,
> -Original Message-
> From: Sousa, Gustavo
> Sent: Monday, May 15, 2023 7:47 AM
> To: Kalvala, Haridhar ; Sripada, Radhakrishna
> ; intel-gfx@lists.freedesktop.org
> Cc: Justen, Jordan L ; Roper, Matthew D
>
> Subject: Re: [PATCH v2 2/2] drm/i915/mtl: Add MTL performance tuning
> changes
>
> Quoting Kalvala, Haridhar (2023-05-14 08:13:10)
> >
> >On 5/13/2023 7:44 AM, Radhakrishna Sripada wrote:
> >> MTL reuses the tuning parameters for DG2. Extend the dg2
> >> performance tuning parameters to MTL.
> >>
> >> v2: Add DRAW_WATERMARK tuning parameter.
> >>
> >> Bspec: 68331
> >> Cc: Haridhar Kalvala
> >> Cc: Matt Roper
> >> Cc: Gustavo Sousa
> >> Signed-off-by: Radhakrishna Sripada
> >> ---
> >> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 ++--
> >> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> index 786349e95487..72dab970de5b 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> >> @@ -817,6 +817,10 @@ static void mtl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> >> {
> >> struct drm_i915_private *i915 = engine->i915;
> >>
> >> +dg2_ctx_gt_tuning_init(engine, wal);
> >> +
> >> +wa_add(wal, DRAW_WATERMARK, VERT_WM_VAL, 0x3FF, 0, false);
> >
> >Hi RK,
> >
> >I am not sure but have doubt w.r.t DRAW_WATERMARK are we not doing same
> >in [ Patch V2 1/2].
> >
> >Thank you,
> >
> >Haridhar Kalvala
>
> Yeah, I think this should be executed only for B0+ steps.
This is a onetime tuning parameter configuration applicable across all MTL.
The wa limitation is independent of the tuning parameter configuration.
- Radhakrishna Sripada
>
> --
> Gustavo Sousa
>
> >
> >> +
> >> if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> >> IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0)) {
> >> /* Wa_14014947963 */
> >> @@ -1754,7 +1758,7 @@ static void gt_tuning_settings(struct intel_gt *gt,
> struct i915_wa_list *wal)
> >> wa_mcr_masked_en(wal, XEHPC_LNCFMISCCFGREG0,
> XEHPC_HOSTCACHEEN);
> >> }
> >>
> >> -if (IS_DG2(gt->i915)) {
> >> +if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915)) {
> >> wa_mcr_write_or(wal, XEHP_L3SCQREG7,
> BLEND_FILL_CACHING_OPT_DIS);
> >> wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
> >> }
> >> @@ -2944,7 +2948,7 @@ static void
> >> add_render_compute_tuning_settings(struct drm_i915_private *i915,
> >> struct i915_wa_list *wal)
> >> {
> >> -if (IS_DG2(i915))
> >> +if (IS_DG2(i915) || IS_METEORLAKE(i915))
> >> wa_mcr_write_clr_set(wal, RT_CTRL, STACKID_CTRL,
> STACKID_CTRL_512);
> >>
> >> /*
> >
> >--
> >Regards,
> >Haridhar Kalvala
> >
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL A-step
Hi Gustavo, > -Original Message- > From: Sousa, Gustavo > Sent: Monday, May 15, 2023 7:45 AM > To: Sripada, Radhakrishna ; intel- > g...@lists.freedesktop.org > Cc: Justen, Jordan L ; Sripada, Radhakrishna > ; Kalvala, Haridhar > ; Roper, Matthew D > > Subject: Re: [PATCH v2 1/2] drm/i915/mtl: Extend Wa_16014892111 to MTL A- > step > > Quoting Radhakrishna Sripada (2023-05-12 23:14:37) > >The dg2 workaround which is used for performance tuning > >is needed for Meteorlake A-step. > > > >v2: Limit the WA for A-step > > I think what Matt meant in the review for v1 was that this commit should > be rather about the tuning setting rather than the workaround itself. As > such, maybe we should change the commit message so that it focus on the > recommended tuning setting, i.e., instead of "Extend Wa_16014892111 to > MTL A-step" as subject, we should write something like "Apply > recommended tuning setting for ..." and give details. > > That said, since we are focusing on the tuning settings here, I guess > this could be squashed with the second patch and we could add a note > about DRAW_WATERMARK needing Wa_16014892111 for A steps of MTL. There are 2 aspects wrt. DRAW_WATERMARK. One that is a workaround which is applied on each context switch and is only applicable for DG2 and MTL-A step which is what this patch does. The other is the tuning parameter setting which is applicable for all of MTL which is a onetime configuration Handled by the next patch during ctx_workarounds_init. - Radhakrishna Sripada > > -- > Gustavo Sousa > > > > >Bspec: 68331 > >Cc: Haridhar Kalvala > >Cc: Matt Roper > >Cc: Gustavo Sousa > >Signed-off-by: Radhakrishna Sripada > >--- > > drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c > b/drivers/gpu/drm/i915/gt/intel_lrc.c > >index 81a96c52a92b..9c1007c44298 100644 > >--- a/drivers/gpu/drm/i915/gt/intel_lrc.c > >+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > >@@ -1370,7 +1370,9 @@ gen12_emit_indirect_ctx_rcs(const struct > intel_context *ce, u32 *cs) > > cs, GEN12_GFX_CCS_AUX_NV); > > > > /* Wa_16014892111 */ > >-if (IS_DG2(ce->engine->i915)) > >+if (IS_DG2(ce->engine->i915) || > >+IS_MTL_GRAPHICS_STEP(ce->engine->i915, M, STEP_A0, STEP_B0) || > >+IS_MTL_GRAPHICS_STEP(ce->engine->i915, P, STEP_A0, STEP_B0)) > > cs = dg2_emit_draw_watermark_setting(cs); > > > > return cs; > >-- > >2.34.1 > >
Re: [Intel-gfx] [PATCH v11 0/8] drm/i915/pxp: Add MTL PXP Support
Thank you for the patches and the reviews. Pushed. - Radhakrishna(RK) Sripada > -Original Message- > From: dri-devel On Behalf Of Alan > Previn > Sent: Thursday, May 11, 2023 4:18 PM > To: intel-gfx@lists.freedesktop.org > Cc: Teres Alexis, Alan Previn ; Ursulin, > Tvrtko ; Juston Li ; dri- > de...@lists.freedesktop.org; Ceraolo Spurio, Daniele > ; Landwerlin, Lionel G > ; Vivi, Rodrigo ; > Justen, Jordan L > Subject: [PATCH v11 0/8] drm/i915/pxp: Add MTL PXP Support > > This series enables PXP on MTL. On ADL/TGL platforms, we rely on > the mei driver via the i915-mei PXP component interface to establish > a connection to the security firmware via the HECI device interface. > That interface is used to create and teardown the PXP ARB session. > PXP ARB session is created when protected contexts are created. > > In this series, the front end behaviors and interfaces (uapi) remain > the same. We add backend support for MTL but with MTL we directly use > the GSC-CS engine on the MTL GPU device to send messages to the PXP > (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format > of the message is slightly different with a 2-layer packetization > that is explained in detail in Patch #3. Also, the second layer > which is the actual PXP firmware packet is now rev'd to version 4.3 > for MTL that is defined in Patch #5. > > Take note that Patch #4 adds the buffer allocation and gsccs-send- > message without actually being called by the arb-creation code > which gets added in Patch #5. Additionally, a seperate series being > reviewed is introducing a change for session teardown (in pxp front- > end layer that will need backend support by both legacy and gsccs). > If we squash all of these together (buffer-alloc, send-message, > arb-creation and, in future, session-termination), the single patch > will be rather large. That said, we are keeping Patch #4 and #5 > separate for now, but at merge time, we can squash them together > if maintainer requires it. > > Changes from prior revs: >v1 : - fixed when building with CONFIG_PXP disabled. > - more alignment with gsc_mtl_header structure from the HDCP >v2 : - (all following changes as per reviews from Daniele) > - squashed Patch #1 from v1 into the next one. > - replaced unnecessary "uses_gsccs" boolean in the pxp > with "HAS_ENGINE(pxp->ctrl_gt, GSC0)". > - moved the stashing of gsccs resources from a dynamically > allocated opaque handle to an explicit sub-struct in > 'struct intel_pxp'. > - moved the buffer object allocations from Patch #1 of this > series to Patch #5 (but keep the context allocation in > Patch #1). > - used the kernel default ppgtt for the gsccs context. > - optimized the buffer allocation and deallocation code > and drop the need to stash the drm_i915_gem_object. > - use a macro with the right mmio reg base (depending > on root-tile vs media-tile) along with common relative > offset to access all KCR registers thus minimizing > changes to the KCR register access codes. > - fixed bugs in the heci packet request submission code > in Patch #3 (of this series) > - add comments in the mtl-gsc-heci-header regarding the > host-session-handle. > - re-use tee-mutex instead of introducing a gsccs specific > cmd mutex. > - minor cosmetic improvements in Patch #5. > - before creating arb session, ensure intel_pxp_start > first ensures the GSC FW is up and running. > - use 2 second timeout for the pending-bit scenario when > sending command to GSC-FW as per specs. > - simplify intel_pxp_get_irq_gt with addition comments > - redo Patch #7 to minimize the changes without introducing > a common abstraction helper for suspend/resume/init/fini > codes that have to change the kcr power state. >v3 : - rebase onto latest drm-tip with the updated firmware > session invalidation flow > - on Patch#1: move 'mutex_init(>tee_mutex)' to a common > init place in intel_pxp_init since its needed everywhere > (Daniele) > - on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);" > (Daniele) > - on Patch#2: move the introduction of host_session_handle to > Patch#4 where it starts getting used. > - on Patch#4: move host-session-handle initialization to the > allocate-resources during gsccs-init (away from Patch#5) > and add the required call to PXP-firmware to cleanup the > host-session-handle in destroy-resources during gsccs-fini > - on Patch#5: add dispatching of arb session termination > firmware cmd during session teardown (as per latest > upstream flows) >v4 : - Added proper initialization and cleanup of
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Fix the wa number for Wa_22016670082
Thank you all for the reviews. Pushed the changes.
-Radhakrishna(RK) Sripada
> -Original Message-
> From: Upadhyay, Tejas
> Sent: Monday, May 8, 2023 5:22 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: Roper, Matthew D
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/mtl: Fix the wa number for
> Wa_22016670082
>
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Radhakrishna Sripada
> > Sent: Saturday, May 6, 2023 5:16 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Roper, Matthew D
> > Subject: [Intel-gfx] [PATCH] drm/i915/mtl: Fix the wa number for
> > Wa_22016670082
> >
> > Fixes the right lineage number for the workaround.
> >
> > Fixes: a7fa1537b791 ("drm/i915/mtl: Implement Wa_14019141245")
> > Cc: Matt Roper
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index ad9e7f49a6fa..786349e95487 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -1699,7 +1699,7 @@ xelpg_gt_workarounds_init(struct intel_gt *gt,
> > struct i915_wa_list *wal)
> > wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> > wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> >
> > - /* Wa_14019141245 */
> > + /* Wa_22016670082 */
>
> Lineage number looks correct to me. Thanks.
>
> Reviewed-by: Tejas Upadhyay
>
> > wa_write_or(wal, GEN12_SQCNT1, GEN12_STRICT_RAR_ENABLE);
> >
> > if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
> > --
> > 2.34.1
Re: [Intel-gfx] [PATCH v1.1] drm/i915/mtl: Implement Wa_14019141245
Hi Matt,
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, May 4, 2023 4:37 PM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
> Subject: Re: [Intel-gfx] [PATCH v1.1] drm/i915/mtl: Implement
> Wa_14019141245
>
> On Tue, Apr 25, 2023 at 11:30:11AM -0700, Radhakrishna Sripada wrote:
> > Enable strict RAR to prevent spurious GPU hangs.
>
> There's no such workaround as "Wa_14019141245." Were you trying to
> implement Wa_22016670082 instead?
Yes that is the correct WA number. Will send a patch to fix the comment.
- Radhakrishna(RK) Sripada
>
>
> Matt
>
> >
> > v1.1: Rebase
> >
> > Cc: Rodrigo Vivi
> > Cc: Umesh Nerlige Ramappa
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 4
> > drivers/gpu/drm/i915/i915_perf_oa_regs.h| 4
> > 3 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index e8c3b762a92a..af80d2fe739b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -529,6 +529,11 @@
> >
> > #define GEN8_RC6_CTX_INFO _MMIO(0x8504)
> >
> > +#define GEN12_SQCNT1 _MMIO(0x8718)
> > +#define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
> > +#define GEN12_SQCNT1_OABPC REG_BIT(29)
> > +#define GEN12_STRICT_RAR_ENABLE REG_BIT(23)
> > +
> > #define XEHP_SQCM MCR_REG(0x8724)
> > #define EN_32B_ACCESSREG_BIT(30)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index de4f8e2e8e8c..ad9e7f49a6fa 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -1699,6 +1699,9 @@ xelpg_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> > wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> > wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> >
> > + /* Wa_14019141245 */
> > + wa_write_or(wal, GEN12_SQCNT1, GEN12_STRICT_RAR_ENABLE);
> > +
> > if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
> > IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)) {
> > /* Wa_14014830051 */
> > @@ -1707,6 +1710,7 @@ xelpg_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> > /* Wa_14015795083 */
> > wa_write_clr(wal, GEN7_MISCCPCTL,
> GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> > }
> > +
> > /*
> > * Unlike older platforms, we no longer setup implicit steering here;
> > * all MCR accesses are explicitly steered.
> > diff --git a/drivers/gpu/drm/i915/i915_perf_oa_regs.h
> b/drivers/gpu/drm/i915/i915_perf_oa_regs.h
> > index ba103875e19f..e5ac7a8b5cb6 100644
> > --- a/drivers/gpu/drm/i915/i915_perf_oa_regs.h
> > +++ b/drivers/gpu/drm/i915/i915_perf_oa_regs.h
> > @@ -134,10 +134,6 @@
> > #define GDT_CHICKEN_BITS_MMIO(0x9840)
> > #define GT_NOA_ENABLE0x0080
> >
> > -#define GEN12_SQCNT1 _MMIO(0x8718)
> > -#define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
> > -#define GEN12_SQCNT1_OABPC REG_BIT(29)
> > -
> > /* Gen12 OAM unit */
> > #define GEN12_OAM_HEAD_POINTER_OFFSET (0x1a0)
> > #define GEN12_OAM_HEAD_POINTER_MASK0xffc0
> > --
> > 2.34.1
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation
Re: [Intel-gfx] [PATCH 2/4] drm/i915/mtl: Add MTL for remapping CCS FBs
> -Original Message-
> From: Intel-gfx On Behalf Of Juha-
> Pekka Heikkila
> Sent: Thursday, May 4, 2023 3:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/4] drm/i915/mtl: Add MTL for remapping CCS FBs
>
> From: Clint Taylor
>
> Add support for remapping CCS FBs on MTL to remove the restriction
> of the power-of-two sized stride and the 2MB surface offset alignment
> for these FBs.
>
> Signed-off-by: Clint Taylor
> Signed-off-by: Juha-Pekka Heikkila
With Alignment of commit message fixed.
Reviewed-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index e5f637897b5e..c004f08fcfe1 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -1190,7 +1190,8 @@ bool intel_fb_needs_pot_stride_remap(const struct
> intel_framebuffer *fb)
> {
> struct drm_i915_private *i915 = to_i915(fb->base.dev);
>
> - return IS_ALDERLAKE_P(i915) && intel_fb_uses_dpt(>base);
> + return (IS_ALDERLAKE_P(i915) || DISPLAY_VER(i915) >= 14) &&
> + intel_fb_uses_dpt(>base);
> }
>
> static int intel_fb_pitch(const struct intel_framebuffer *fb, int
> color_plane,
> unsigned int rotation)
> @@ -1326,9 +1327,10 @@ plane_view_scanout_stride(const struct
> intel_framebuffer *fb, int color_plane,
> unsigned int tile_width,
> unsigned int src_stride_tiles, unsigned int
> dst_stride_tiles)
> {
> + struct drm_i915_private *i915 = to_i915(fb->base.dev);
> unsigned int stride_tiles;
>
> - if (IS_ALDERLAKE_P(to_i915(fb->base.dev)))
> + if (IS_ALDERLAKE_P(i915) || DISPLAY_VER(i915) >= 14)
> stride_tiles = src_stride_tiles;
> else
> stride_tiles = dst_stride_tiles;
> @@ -1522,7 +1524,8 @@ static void intel_fb_view_init(struct drm_i915_private
> *i915, struct intel_fb_vi
> memset(view, 0, sizeof(*view));
> view->gtt.type = view_type;
>
> - if (view_type == I915_GTT_VIEW_REMAPPED &&
> IS_ALDERLAKE_P(i915))
> + if (view_type == I915_GTT_VIEW_REMAPPED &&
> + (IS_ALDERLAKE_P(i915) || DISPLAY_VER(i915) >= 14))
> view->gtt.remapped.plane_alignment = SZ_2M / PAGE_SIZE;
> }
>
> --
> 2.25.1
Re: [Intel-gfx] [PATCH v2 00/13] drm/i915/mtl: Add support for C20 phy
Fixed the parenthesis alignment in patch 02 and pushed the series. Thank you for the patches. -Radhakrishna(RK) Sripada > -Original Message- > From: Intel-gfx On Behalf Of Mika > Kahola > Sent: Friday, April 28, 2023 2:54 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 00/13] drm/i915/mtl: Add support for C20 phy > > Add support for C20 phy for Type-C connections. C20 phy differs from > C10 and hence we need to separately handle this case. > > v2: Fixes for C20 pll programming and hw readout > > Signed-off-by: Mika Kahola > > Anusha Srivatsa (1): > drm/i915/mtl: Pin assignment for TypeC > > Gustavo Sousa (1): > drm/i915/mtl: Define mask for DDI AUX interrupts > > Imre Deak (1): > drm/i915/mtl: TypeC HPD live status query > > Mika Kahola (10): > drm/i915/mtl: C20 PLL programming > drm/i915/mtl: C20 HW readout > drm/i915/mtl: Dump C20 pll hw state > drm/i915/mtl: C20 port clock calculation > drm/i915/mtl: Add voltage swing sequence for C20 > drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA > drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll > drm/i915/mtl: Readout Thunderbolt HW state > drm/i915/mtl: Power up TCSS > drm/i915/mtl: Enable TC ports > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 1137 - > drivers/gpu/drm/i915/display/intel_cx0_phy.h | 23 +- > .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 41 + > drivers/gpu/drm/i915/display/intel_ddi.c | 25 +- > .../drm/i915/display/intel_ddi_buf_trans.c| 53 +- > drivers/gpu/drm/i915/display/intel_display.c |7 +- > .../drm/i915/display/intel_display_types.h| 16 +- > drivers/gpu/drm/i915/display/intel_dp.c | 12 +- > drivers/gpu/drm/i915/display/intel_dpll.c |2 + > drivers/gpu/drm/i915/display/intel_hdmi.c |6 +- > drivers/gpu/drm/i915/display/intel_hdmi.h |1 + > drivers/gpu/drm/i915/display/intel_tc.c | 255 +++- > drivers/gpu/drm/i915/i915_irq.c |5 +- > 13 files changed, 1510 insertions(+), 73 deletions(-) > > -- > 2.34.1
Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
> -Original Message-
> From: Kahola, Mika
> Sent: Wednesday, April 26, 2023 4:43 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
>
> > -Original Message-
> > From: Sripada, Radhakrishna
> > Sent: Monday, April 24, 2023 11:56 PM
> > To: Kahola, Mika
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
> >
> > On Thu, Apr 20, 2023 at 03:40:39PM +0300, Mika Kahola wrote:
> > > Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> > > The PLL settings are based on table, not for algorithmic alternative.
> > > For DP 1.4 only MPLLB is in use.
> > >
> > > Once register settings are done, we read back C20 HW state.
> > >
> > > BSpec: 64568
> > >
> > > Signed-off-by: Mika Kahola
> > > Signed-off-by: Arun R Murthy
> > > Signed-off-by: Ankit Nautiyal
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 623 +-
> > > drivers/gpu/drm/i915/display/intel_cx0_phy.h | 8 +-
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> > > .../drm/i915/display/intel_display_types.h| 1 +
> > > drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +-
> > > drivers/gpu/drm/i915/display/intel_hdmi.h | 1 +
> > > 6 files changed, 628 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > index dd96bf5e179e..61428c5145e5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > > @@ -11,6 +11,7 @@
> > > #include "intel_de.h"
> > > #include "intel_display_types.h"
> > > #include "intel_dp.h"
> > > +#include "intel_hdmi.h"
> > > #include "intel_panel.h"
> > > #include "intel_psr.h"
> > > #include "intel_tc.h"
> > > @@ -285,6 +286,23 @@ static void intel_c20_sram_write(struct
> > drm_i915_private *i915, enum port port,
> > > intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > > 1); }
> > >
> > > +static u16 intel_c20_sram_read(struct drm_i915_private *i915, enum port
> > port,
> > > +int lane, u16 addr)
> > > +{
> > > + u16 val;
> > > +
> > > + assert_dc_off(i915);
> > > +
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, addr >> 8,
> > 0);
> > > + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff,
> > > +1);
> > > +
> > > + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> > > + val <<= 8;
> > > + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> > > +
> > > + return val;
> > > +}
> > > +
> > > static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port
> > > port,
> > > int lane, u16 addr, u8 clear, u8 set, bool
> > > committed) {
> > @@
> > > -659,6 +677,199 @@ static const struct intel_c10pll_state * const
> > mtl_c10_edp_tables[] = {
> > > NULL,
> > > };
> > >
> > > +/* C20 basic DP 1.4 tables */
> > > +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> > > + .link_bit_rate = 162000,
> > > + .clock = 162000,
> > > + .tx = { 0xbe88, /* tx cfg0 */
> > > + 0x5800, /* tx cfg1 */
> > > + 0x, /* tx cfg2 */
> > > + },
> > > + .cmn = {0x0500, /* cmn cfg0*/
> > > + 0x0005, /* cmn cfg1 */
> > > + 0x, /* cmn cfg2 */
> > > + 0x, /* cmn cfg3 */
> > > + },
> > > + .mpllb = { 0x50a8, /* mpllb cfg0 */
> > > + 0x2120, /* mpllb cfg1 */
> > > + 0xcd9a, /* mpllb cfg2 */
> > > + 0xbfc1, /* mpllb cfg3 */
> > > + 0x5ab8, /* mpllb cfg4 */
> > > + 0x4c34, /* mpllb cfg5 */
> > > + 0x2000, /* mpllb cfg6 */
> > > + 0x0001, /* mpllb cfg7 */
> > > + 0x6000, /* mpllb cfg8 */
> > > + 0x, /* mpllb cfg9 */
> > > + 0x,
Re: [Intel-gfx] [PATCH v1.1] drm/i915/mtl: Implement Wa_14019141245
> -Original Message-
> From: Kalvala, Haridhar
> Sent: Wednesday, April 26, 2023 5:36 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: Vivi, Rodrigo
> Subject: Re: [Intel-gfx] [PATCH v1.1] drm/i915/mtl: Implement
> Wa_14019141245
>
>
> On 4/26/2023 12:00 AM, Radhakrishna Sripada wrote:
> > Enable strict RAR to prevent spurious GPU hangs.
> >
> > v1.1: Rebase
> >
> > Cc: Rodrigo Vivi
> > Cc: Umesh Nerlige Ramappa
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 4
> > drivers/gpu/drm/i915/i915_perf_oa_regs.h| 4
> > 3 files changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index e8c3b762a92a..af80d2fe739b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -529,6 +529,11 @@
> >
> > #define GEN8_RC6_CTX_INFO _MMIO(0x8504)
> >
> > +#define GEN12_SQCNT1 _MMIO(0x8718)
> > +#define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
> > +#define GEN12_SQCNT1_OABPC REG_BIT(29)
> > +#define GEN12_STRICT_RAR_ENABLE REG_BIT(23)
> > +
> > #define XEHP_SQCM MCR_REG(0x8724)
> > #define EN_32B_ACCESS REG_BIT(30)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index de4f8e2e8e8c..ad9e7f49a6fa 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -1699,6 +1699,9 @@ xelpg_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> > wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> > wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> >
> > + /* Wa_14019141245 */
> > + wa_write_or(wal, GEN12_SQCNT1, GEN12_STRICT_RAR_ENABLE);
> > +
> looks good to me.
> > if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
> > IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)) {
> > /* Wa_14014830051 */
> > @@ -1707,6 +1710,7 @@ xelpg_gt_workarounds_init(struct intel_gt *gt,
> struct i915_wa_list *wal)
> > /* Wa_14015795083 */
> > wa_write_clr(wal, GEN7_MISCCPCTL,
> GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> > }
> > +
> > /*
> > * Unlike older platforms, we no longer setup implicit steering here;
> > * all MCR accesses are explicitly steered.
> > diff --git a/drivers/gpu/drm/i915/i915_perf_oa_regs.h
> b/drivers/gpu/drm/i915/i915_perf_oa_regs.h
> > index ba103875e19f..e5ac7a8b5cb6 100644
> > --- a/drivers/gpu/drm/i915/i915_perf_oa_regs.h
> > +++ b/drivers/gpu/drm/i915/i915_perf_oa_regs.h
> > @@ -134,10 +134,6 @@
> > #define GDT_CHICKEN_BITS_MMIO(0x9840)
> > #define GT_NOA_ENABLE 0x0080
> >
> > -#define GEN12_SQCNT1 _MMIO(0x8718)
> > -#define GEN12_SQCNT1_PMON_ENABLE REG_BIT(30)
> > -#define GEN12_SQCNT1_OABPC REG_BIT(29)
> These two register bit and register(0x8718) moved to "
> intel_gt_regs.h"not getting used elsewhere(I mean, in i915_perf.c) ?
1) i915_perf.c includes gt/intel_gt_regs.h so moving the register def. there
should not cause any problem.
Moreover,
2) intel_gt_regs.h is used across almost all the files under i915/gt.
i915_perf_oa_regs.h do not have that kind of usage.
3) because of this bit, the usage of this register is not limited to perf
subsystem.
Hence the better place in intel_gt_regs.h.
4) we need not have all the i915_pref_oa_regs.h definitions included in
intel_workarounds.c
- Radhakrishna(RK) Sripada
> > -
> > /* Gen12 OAM unit */
> > #define GEN12_OAM_HEAD_POINTER_OFFSET (0x1a0)
> > #define GEN12_OAM_HEAD_POINTER_MASK0xffc0
>
> --
> Regards,
> Haridhar Kalvala
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/mtl: Extend Wa_22011802037 to MTL A-step
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, April 21, 2023 8:09 AM
> To: Atwood, Matthew S
> Cc: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/mtl: Extend Wa_22011802037
> to MTL A-step
>
> On Fri, Apr 21, 2023 at 08:05:50AM -0700, Matt Roper wrote:
> > On Wed, Apr 19, 2023 at 02:40:33PM -0700, Matt Atwood wrote:
> > > On Tue, Apr 18, 2023 at 03:04:45PM -0700, Radhakrishna Sripada wrote:
> > > > From: Madhumitha Tolakanahalli Pradeep
>
> > > >
> > > > Wa_22011802037 was being applied to all graphics_ver 11 & 12. This patch
> > > > updates the if statement to apply the W/A to right platforms and extends
> > > > it to MTL-M:A step.
> > > >
> > > Bspec: 53509
> > > > v1.1: Fix checkpatch warning.
> > > > v2: Change the check to reflect the wa at other palces(Lucas)
> > > s/palces/places.
> > > >
> > > > Cc: Lucas De Marchi
> > > > Cc: Umesh Nerlige Ramappa
> > > With that.
> > > Reviewed-by: Matt Atwood
> > > > Signed-off-by: Madhumitha Tolakanahalli Pradeep
>
> > > > Signed-off-by: Radhakrishna Sripada
> >
> > It doesn't look like this patch is complete? It's only changing one
> > condition for Wa_22011802037, even though there are several in the code.
> > From a quick grep, you're still missing updates for at least
> > guc_ctl_wa_flags, execlists_reset_prepare, and __intel_engine_stop_cs.
>
> Actually, scratch that. Those other spots already have a MTL clause as
> part of the condition. But in that case it means the commit message
> here is inaccurate; you're not extending this workaround to MTL a-step
> because that already happened on a previous patch. You're just
> providing a fix for an incomplete implementation that happened earlier.
> The commit message should be explaining that.
>
> >
> > Since this workaround is a complicated one that touches so many areas of
> > the code, and has a complex platform list, it's probably time to factor
> > the condition out into a needs_wa_22011802037() helper or something.
>
> I still suggest doing this, especially since we've clearly screwed up
> the handling of this workaround at least once already.
>
Sure Matt. With the patch already merged, I will handle this as a separate
patch.
- Radhakrishna(RK) Sripada
>
> Matt
>
> >
> >
> > Matt
> >
> > > > ---
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 ++--
> > > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > index 88e881b100cf..ee3e8352637f 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > @@ -1629,16 +1629,16 @@ static void guc_reset_state(struct
> intel_context *ce, u32 head, bool scrub)
> > > >
> > > > static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
> > > > {
> > > > - if (!IS_GRAPHICS_VER(engine->i915, 11, 12))
> > > > - return;
> > > > -
> > > > - intel_engine_stop_cs(engine);
> > > > -
> > > > /*
> > > > * Wa_22011802037: In addition to stopping the cs, we need
> > > > * to wait for any pending mi force wakeups
> > > > */
> > > > - intel_engine_wait_for_pending_mi_fw(engine);
> > > > + if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
> > > > + (GRAPHICS_VER(engine->i915) >= 11 &&
> > > > +GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70))) {
> > > > + intel_engine_stop_cs(engine);
> > > > + intel_engine_wait_for_pending_mi_fw(engine);
> > > > + }
> > > > }
> > > >
> > > > static void guc_reset_nop(struct intel_engine_cs *engine)
> > > > --
> > > > 2.34.1
> > > >
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > Linux GPU Platform Enablement
> > Intel Corporation
>
> --
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use separate "DC off" power well for ADL-P and DG2
> -Original Message-
> From: Deak, Imre
> Sent: Friday, March 17, 2023 10:43 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org; De Marchi, Lucas
>
> Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use separate "DC off" power
> well
> for ADL-P and DG2
>
> On Thu, Mar 16, 2023 at 01:25:45PM -0700, Radhakrishna Sripada wrote:
> > From: Matt Roper
> >
> > Although ADL-P and DG2 both use the same general power well setup, the
> > DC5/DC6 requirements are slightly different which means each platform
> > should have its own "DC off" power well.
> >
> > DG2 (i.e., Xe_HPD IP) requires that DC5 be disabled whenever PG2 is
> > active. However ADL-P (i.e., Xe_LPD IP) only requires DC5/DC6 to be
> > disabled when the PGC or PGD subwells are active; we should be able to
> > remain in these DC states when PGB and general PG2 functionality is in
> > use.
> >
> > Bspec: 49193
> > Signed-off-by: Matt Roper
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > .../i915/display/intel_display_power_map.c| 41 +--
> > 1 file changed, 38 insertions(+), 3 deletions(-)
> >
> > 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 6645eb1911d8..d9e02cc9cf3c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > @@ -1301,7 +1301,8 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_2,
> > */
> >
> > I915_DECL_PW_DOMAINS(xelpd_pwdoms_dc_off,
> > - XELPD_PW_2_POWER_DOMAINS,
> > + XELPD_PW_C_POWER_DOMAINS,
> > + XELPD_PW_D_POWER_DOMAINS,
> > POWER_DOMAIN_PORT_DSI,
> > POWER_DOMAIN_AUDIO_MMIO,
> > POWER_DOMAIN_AUX_A,
> > @@ -1310,14 +1311,38 @@
> I915_DECL_PW_DOMAINS(xelpd_pwdoms_dc_off,
> > POWER_DOMAIN_DC_OFF,
> > POWER_DOMAIN_INIT);
> >
> > -static const struct i915_power_well_desc xelpd_power_wells_main[] = {
> > +static const struct i915_power_well_desc xelpd_power_wells_dcoff[] = {
>
> Nit: Here and in the xehpd defintion, s/dcoff/dc_off/ to match other
> platforms.
>
> > {
> > .instances = _PW_INSTANCES(
> > I915_PW("DC_off", _pwdoms_dc_off,
> > .id = SKL_DISP_DC_OFF),
> > ),
> > .ops = _dc_off_power_well_ops,
> > - }, {
> > + }
> > +};
> > +
> > +I915_DECL_PW_DOMAINS(xehpd_pwdoms_dc_off,
> > + XELPD_PW_2_POWER_DOMAINS,
> > + POWER_DOMAIN_PORT_DSI,
> > + POWER_DOMAIN_AUDIO_MMIO,
> > + POWER_DOMAIN_AUX_A,
> > + POWER_DOMAIN_AUX_B,
> > + POWER_DOMAIN_MODESET,
> > + POWER_DOMAIN_DC_OFF,
> > + POWER_DOMAIN_INIT);
> > +
> > +static const struct i915_power_well_desc xehpd_power_wells_dcoff[] = {
> > + {
> > + .instances = _PW_INSTANCES(
> > + I915_PW("DC_off", _pwdoms_dc_off,
> > + .id = SKL_DISP_DC_OFF),
> > + ),
> > + .ops = _dc_off_power_well_ops,
> > + }
> > +};
>
> Could you move the xehpd definitions to precede xehpd_power_wells[]?
>
> Patches 1, 2 look ok to me:
> Reviewed-by: Imre Deak
Thank you for the R-b merged Patches 1, 2
- Radhakrishna(RK) Sripada
>
> > +
> > +static const struct i915_power_well_desc xelpd_power_wells_main[] = {
> > + {
> > .instances = _PW_INSTANCES(
> > I915_PW("PW_2", _pwdoms_pw_2,
> > .hsw.idx = ICL_PW_CTL_IDX_PW_2,
> > @@ -1400,6 +1425,14 @@ static const struct i915_power_well_desc
> xelpd_power_wells_main[] = {
> > static const struct i915_power_well_desc_list xelpd_power_wells[] = {
> > I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
> > I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
> > + I915_PW_DESCRIPTORS(xelpd_power_wells_dcoff),
> > + I915_PW_DESCRIPTORS(xelpd_power_wells_main),
> > +};
> > +
> > +static const struct i915_power_well_desc_list xehpd_power_wells[] = {
> > + I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
> > + I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
> > + I915_PW_DESCRIPTORS(xehpd_power_wells_dcoff),
> > I915_PW_DESCRIPTORS(xelpd_power_wells_main),
> > };
> >
> > @@ -1624,6 +1657,8 @@ int intel_display_power_map_init(struct
> i915_power_domains *power_domains)
> >
> > if (DISPLAY_VER(i915) >= 14)
> > return set_power_wells(power_domains, xelpdp_power_wells);
> > + else if (IS_DG2(i915))
> > + return set_power_wells(power_domains, xehpd_power_wells);
> > else if (DISPLAY_VER(i915) >= 13)
> > return set_power_wells(power_domains, xelpd_power_wells);
> > else if (IS_DG1(i915))
> > --
> > 2.34.1
> >
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/mtl: WA to clear RDOP clock gating
Thank you for the review. Merged both the workarounds with updated Bspec page. - Radhakrishna(RK) Sripada > -Original Message- > From: Atwood, Matthew S > Sent: Wednesday, April 19, 2023 2:49 PM > To: Sripada, Radhakrishna ; intel- > g...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/mtl: WA to clear RDOP clock > gating > > On Tue, Apr 18, 2023 at 03:04:46PM -0700, Radhakrishna Sripada wrote: > > From: Haridhar Kalvala > > > > Workaround implementation to clear RDOP clock gating. > > > > Bspec: 33453 > A better bspec value here is 53509, you're referencing a non-updating > page > > > With that. > Reviewed-by: Matt Atwood > > Signed-off-by: Haridhar Kalvala > > Signed-off-by: Radhakrishna Sripada > > --- > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > > index b925ef47304b..312eb8b5f949 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > > @@ -1703,6 +1703,9 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, > struct i915_wa_list *wal) > > /* Wa_18018781329 */ > > wa_mcr_write_or(wal, RENDER_MOD_CTRL, > FORCE_MISS_FTLB); > > wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB); > > + > > + /* Wa_14015795083 */ > > + wa_write_clr(wal, GEN7_MISCCPCTL, > GEN12_DOP_CLOCK_GATE_RENDER_ENABLE); > > } > > > > /* > > -- > > 2.34.1 > >
Re: [Intel-gfx] [PATCH 7/9] drm/i915/mtl: Add C10 phy programming for HDMI
Thank you for the review Imre and Mika for submitting the patches.
Pushed the series onto drm-tip.
-Radhakrishna(RK) Sripada
> -Original Message-
> From: Deak, Imre
> Sent: Friday, April 14, 2023 4:39 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 7/9] drm/i915/mtl: Add C10 phy programming for HDMI
>
> On Thu, Apr 13, 2023 at 02:24:41PM -0700, Radhakrishna Sripada wrote:
> > Like DG2, we still don't have a proper algorithm that can be used
> > for calculating PHY settings, but we do have tables of register
> > values for a handful of the more common link rates. Some support is
> > better than none, so let's go ahead and add/use these tables when we
> > can, and also add some logic to hdmi_port_clock_valid() to filter the
> > modelist to just the modes we can actually support with these link
> > rates.
> >
> > Hopefully we'll have a proper / non-encumbered algorithm to calculate
> > these registers by the time we upstream and we'll be able to replace
> > this patch with something more general purpose.
> >
> > Bspec: 64568
> >
> > v2: Rebasing with Clint's HDMI C10 PLL tables (Mika)
> > v3: Remove the extra hdmi clock check pruning.
> >
> > Cc: Imre Deak
> > Cc: Uma Shankar
> > Signed-off-by: Radhakrishna Sripada
> > Signed-off-by: Clint Taylor
> > Signed-off-by: Mika Kahola
> > Signed-off-by: Ankit Nautiyal
> > Link:
> https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-6-
> mika.kah...@intel.com
>
> Reviewed-by: Imre Deak
>
> > ---
> > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 610 +-
> > drivers/gpu/drm/i915/display/intel_cx0_phy.h | 1 +
> > .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 2 +
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +-
> > 4 files changed, 614 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index 5ffd661fa507..d46ff3401e5e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -647,6 +647,603 @@ static const struct intel_c10pll_state * const
> mtl_c10_edp_tables[] = {
> > NULL,
> > };
> >
> > +/*
> > + * HDMI link rates with 38.4 MHz reference clock.
> > + */
> > +
> > +static const struct intel_c10pll_state mtl_c10_hdmi_25_2 = {
> > + .clock = 25200,
> > + .tx = 0x10,
> > + .cmn = 0x1,
> > + .pll[0] = 0x4,
> > + .pll[1] = 0,
> > + .pll[2] = 0xB2,
> > + .pll[3] = 0,
> > + .pll[4] = 0,
> > + .pll[5] = 0,
> > + .pll[6] = 0,
> > + .pll[7] = 0,
> > + .pll[8] = 0x20,
> > + .pll[9] = 0x1,
> > + .pll[10] = 0,
> > + .pll[11] = 0,
> > + .pll[12] = 0,
> > + .pll[13] = 0,
> > + .pll[14] = 0,
> > + .pll[15] = 0xD,
> > + .pll[16] = 0x6,
> > + .pll[17] = 0x8F,
> > + .pll[18] = 0x84,
> > + .pll[19] = 0x23,
> > +};
> > +
> > +static const struct intel_c10pll_state mtl_c10_hdmi_27_0 = {
> > + .clock = 27000,
> > + .tx = 0x10,
> > + .cmn = 0x1,
> > + .pll[0] = 0x34,
> > + .pll[1] = 0,
> > + .pll[2] = 0xC0,
> > + .pll[3] = 0,
> > + .pll[4] = 0,
> > + .pll[5] = 0,
> > + .pll[6] = 0,
> > + .pll[7] = 0,
> > + .pll[8] = 0x20,
> > + .pll[9] = 0x1,
> > + .pll[10] = 0,
> > + .pll[11] = 0,
> > + .pll[12] = 0x80,
> > + .pll[13] = 0,
> > + .pll[14] = 0,
> > + .pll[15] = 0xD,
> > + .pll[16] = 0x6,
> > + .pll[17] = 0xCF,
> > + .pll[18] = 0x84,
> > + .pll[19] = 0x23,
> > +};
> > +
> > +static const struct intel_c10pll_state mtl_c10_hdmi_74_25 = {
> > + .clock = 74250,
> > + .tx = 0x10,
> > + .cmn = 0x1,
> > + .pll[0] = 0xF4,
> > + .pll[1] = 0,
> > + .pll[2] = 0x7A,
> > + .pll[3] = 0,
> > + .pll[4] = 0,
> > + .pll[5] = 0,
> > + .pll[6] = 0,
> > + .pll[7] = 0,
> > + .pll[8] = 0x20,
> > + .pll[9] = 0x1,
> > + .pll[10] = 0,
> > + .pll[11] = 0,
> > + .pll[12] = 0x58,
> > + .pll[13] = 0,
> > + .pll[14] = 0,
> > + .pll[15] = 0xB,
> > + .pll[16] = 0x6,
> > + .pll[17] = 0xF,
> > + .pll[18] = 0x85,
> > + .pll[19] = 0x23,
> > +};
> > +
> > +static const struct intel_c10pll_state mtl_c10_hdmi_148_5 = {
> > + .clock = 148500,
&
Re: [Intel-gfx] [PATCH 8/9] drm/i915/mtl: Add C10 phy programming for HDMI
> -Original Message-
> From: Deak, Imre
> Sent: Thursday, April 13, 2023 9:37 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 8/9] drm/i915/mtl: Add C10 phy programming for HDMI
>
> On Wed, Apr 12, 2023 at 03:49:24PM -0700, Radhakrishna Sripada wrote:
> > [...]
> > +/* Precomputed C10 HDMI PLL tables */
> > +static const struct intel_c10pll_state mtl_c10_hdmi_25175 = {
> > + .clock = 25175,
> > + .tx = 0x10,
> > + .cmn = 0x1,
> > + .pll[0] = 0x34,
> > + .pll[1] = 0x00,
> > + .pll[2] = 0xB0,
> > + .pll[3] = 0x00,
> > + .pll[4] = 0x00,
> > + .pll[5] = 0x00,
> > + .pll[6] = 0x00,
> > + .pll[7] = 0x00,
> > + .pll[8] = 0x20,
> > + .pll[9] = 0xFF,
> > + .pll[10] = 0xFF,
> > + .pll[11] = 0x55,
> > + .pll[12] = 0xE5,
> > + .pll[13] = 0x55,
> > + .pll[14] = 0x55,
> > + .pll[15] = 0x0D,
> > + .pll[16] = 0x09,
> > + .pll[17] = 0x8F,
> > + .pll[18] = 0x84,
> > + .pll[19] = 0x23,
> > +};
>
> Something off with the above table,
> intel_c10pll_calc_port_clock() calculates 25200 clock rate for it. So
> either .clock above needs to be the same rate, or the PLL params need to
> be corrected for the 25175 rate.
We do have a pre-computed table for 25200 clock which has different values.
Do we skip this clock for now?
-RK
>
> > [...]
> > @@ -690,9 +1315,20 @@ static void intel_c10pll_update_pll(struct
> intel_crtc_state *crtc_state,
> > static int intel_c10pll_calc_state(struct intel_crtc_state *crtc_state,
> >struct intel_encoder *encoder)
> > {
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > const struct intel_c10pll_state * const *tables;
> > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > int i;
> >
> > + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> > + if (intel_c10_phy_check_hdmi_link_rate(crtc_state->port_clock)
> > + != MODE_OK) {
> > + drm_dbg_kms(>drm, "Can't support HDMI link
> rate %d on phy %c.\n",
> > + crtc_state->port_clock, phy_name(phy));
> > + return -EINVAL;
> > + }
> > + }
>
> The above check is not needed, covered already by the loop later in
> the function.
>
> > +
> > tables = intel_c10pll_tables_get(crtc_state, encoder);
> > if (!tables)
> > return -EINVAL;
Re: [Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, April 4, 2023 11:03 AM
> To: Sripada, Radhakrishna
> Cc: Kahola, Mika ; intel-gfx@lists.freedesktop.org;
> Shankar, Uma ; Sousa, Gustavo
>
> Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus
> and pll programming
>
> On Tue, Apr 04, 2023 at 07:50:00PM +0300, Sripada, Radhakrishna wrote:
> >
> >
> > > -Original Message-
> > > From: Deak, Imre
> > > Sent: Tuesday, April 4, 2023 6:28 AM
> > > To: Kahola, Mika
> > > Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna
> > > ; Shankar, Uma
> ;
> > > Sousa, Gustavo
> > > Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message
> bus
> > > and pll programming
> > >
> > > On Tue, Apr 04, 2023 at 04:01:55PM +0300, Kahola, Mika wrote:
> > > > [...]
> > > > > >
> > > > > > > > +void intel_c10mpllb_readout_hw_state(struct intel_encoder
> *encoder,
> > > > > > > > +struct intel_c10mpllb_state
> > > > > > > > pll_state) {
> > > > > > > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > > > > > > + struct intel_digital_port *dig_port =
> > > > > > > > enc_to_dig_port(encoder);
> > > > > > > > + bool lane_reversal = dig_port->saved_port_bits &
> DDI_BUF_PORT_REVERSAL;
> > > > > > > > + u8 lane = lane_reversal ? INTEL_CX0_LANE1 :
> > > > > > > > + INTEL_CX0_LANE0;
> > > > > > > > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > > > > > > + int i;
> > > > > > > > + u8 cmn, tx0;
> > > > > > > > +
> > > > > > > > + /*
> > > > > > > > +* According to C10 VDR Register programming Sequence we
> need
> > > > > > > > +* to do this to read PHY internal registers from MsgBus.
> > > > > > > > +*/
> > > > > > > > + intel_cx0_rmw(i915, encoder->port, lane,
> PHY_C10_VDR_CONTROL(1), 0,
> > > > > > > > + C10_VDR_CTRL_MSGBUS_ACCESS,
> MB_WRITE_COMMITTED);
> > > > > > > > +
> > > > > > > > + for (i = 0; i < ARRAY_SIZE(pll_state->pll); i++)
> > > > > > > > + pll_state->pll[i] = intel_cx0_read(i915,
> > > > > > > > encoder->port, lane,
> PHY_C10_VDR_PLL(i));
> > > > > > > > +
> > > > > > > > + cmn = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_CMN(0));
> > > > > > > > + tx0 = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_TX(0));
> > > > > > >
> > > > > > > The driver programs these registers, so why aren't they also
> > > > > > > stored
> > > > > > > in the intell_c20pll_state struct?
> > > > > >
> > > > > > Maybe I'm not really following here but intel_c20pll_state has its
> > > > > > own
> > > > > > tx, cmn and mplla/mpllb stored.
> > > > >
> > > > > Yes, just typoed that, I meant struct intel_c10mpllb_state which
> > > > > doesn't include tx and cmn.
> > > >
> > > > Yes, for C10 tx and cmn is missing. Maybe we could add those here as
> > > > well. It seems that currently these are not necessary required but for
> > > > the future use, these could be defined.
> > >
> > > These are needed already now to make the state computation / HW readout
> /
> > > state checking work for these two params the same way they do for the
> > > rest of PLL state.
> >
> > I believe C10 tx and cmn values are not changing across frequencies. Cmn
> > only
> > Changes for DP and HDMI so does it make sense to include in the pll
> > structure?
>
> They should be part of the atomic state. To save the bytes in the
> precomputed tables they could be added to intel_cx0pll_state, something
> like:
>
> struct intel_cx0pll_state {
> union {
> struct {
> struct intel_c10mpllb_state pllb;
> u8 cmn;
> u8 tx;
> } c10;
> struct intel_c20pll_state c20pll_state;
> };
> };
>
I am bit concerned about the mismatch in the names for c10 and c20 states,
adding further complexity in the structure may look more ugly. Let us afford the
extra space in the tables if they need to be part of the atomic state and
maintain
homogeneity across c10 and c20 structures.
Thoughts?
-RK
> --Imre
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Disable stolen memory backed FB for A0
> -Original Message- > From: Das, Nirmoy > Sent: Tuesday, April 4, 2023 11:14 AM > To: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; Das, Nirmoy ; > Auld, Matthew ; Andi Shyti > ; Ceraolo Spurio, Daniele > ; De Marchi, Lucas > ; Sripada, Radhakrishna > > Subject: [PATCH v3] drm/i915/mtl: Disable stolen memory backed FB for A0 > > Stolen memory is not usable for MTL A0 stepping beyond > certain access size and we have no control over userspace > access size of /dev/fb which can be backed by stolen memory. > So disable stolen memory backed fb by setting i915->dsm.usable_size > to zero. > > v2: remove hsdes reference and fix commit message(Andi) > v3: use revid as we want to target SOC stepping(Radhakrishna) > > Cc: Matthew Auld > Cc: Andi Shyti > Cc: Daniele Ceraolo Spurio > Cc: Lucas De Marchi > Cc: Radhakrishna Sripada > Signed-off-by: Nirmoy Das > Reviewed-by: Andi Shyti LGTM, Reviewed-by: Radhakrishna Sripada > --- > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > index 8ac376c24aa2..ee492d823f1b 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c > @@ -535,6 +535,14 @@ static int i915_gem_init_stolen(struct > intel_memory_region *mem) > /* Basic memrange allocator for stolen space. */ > drm_mm_init(>mm.stolen, 0, i915->dsm.usable_size); > > + /* > + * Access to stolen lmem beyond certain size for MTL A0 stepping > + * would crash the machine. Disable stolen lmem for userspace access > + * by setting usable_size to zero. > + */ > + if (IS_METEORLAKE(i915) && INTEL_REVID(i915) == 0x0) > + i915->dsm.usable_size = 0; > + > return 0; > } > > -- > 2.39.0
Re: [Intel-gfx] [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, April 4, 2023 6:28 AM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna
> ; Shankar, Uma ;
> Sousa, Gustavo
> Subject: Re: [PATCH 4/7] drm/i915/mtl: Add Support for C10 PHY message bus
> and pll programming
>
> On Tue, Apr 04, 2023 at 04:01:55PM +0300, Kahola, Mika wrote:
> > [...]
> > > >
> > > > > > +void intel_c10mpllb_readout_hw_state(struct intel_encoder
> *encoder,
> > > > > > +struct intel_c10mpllb_state
> > > > > > +*pll_state) {
> > > > > > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > > > > > + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > > > > > + bool lane_reversal = dig_port->saved_port_bits &
> DDI_BUF_PORT_REVERSAL;
> > > > > > + u8 lane = lane_reversal ? INTEL_CX0_LANE1 :
> > > > > > + INTEL_CX0_LANE0;
> > > > > > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > > > > > + int i;
> > > > > > + u8 cmn, tx0;
> > > > > > +
> > > > > > + /*
> > > > > > +* According to C10 VDR Register programming Sequence we need
> > > > > > +* to do this to read PHY internal registers from MsgBus.
> > > > > > +*/
> > > > > > + intel_cx0_rmw(i915, encoder->port, lane,
> PHY_C10_VDR_CONTROL(1), 0,
> > > > > > + C10_VDR_CTRL_MSGBUS_ACCESS,
> MB_WRITE_COMMITTED);
> > > > > > +
> > > > > > + for (i = 0; i < ARRAY_SIZE(pll_state->pll); i++)
> > > > > > + pll_state->pll[i] = intel_cx0_read(i915, encoder->port,
> > > > > > lane,
> PHY_C10_VDR_PLL(i));
> > > > > > +
> > > > > > + cmn = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_CMN(0));
> > > > > > + tx0 = intel_cx0_read(i915, encoder->port, lane,
> PHY_C10_VDR_TX(0));
> > > > >
> > > > > The driver programs these registers, so why aren't they also stored
> > > > > in the intell_c20pll_state struct?
> > > >
> > > > Maybe I'm not really following here but intel_c20pll_state has its own
> > > > tx, cmn and mplla/mpllb stored.
> > >
> > > Yes, just typoed that, I meant struct intel_c10mpllb_state which
> > > doesn't include tx and cmn.
> >
> > Yes, for C10 tx and cmn is missing. Maybe we could add those here as
> > well. It seems that currently these are not necessary required but for
> > the future use, these could be defined.
>
> These are needed already now to make the state computation / HW readout /
> state checking work for these two params the same way they do for the
> rest of PLL state.
I believe C10 tx and cmn values are not changing across frequencies. Cmn on ly
Changes for DP and HDMI so does it make sense to include in the pll structure?
-RK
>
> > > > > > +
> > > > > > + if (tx0 != C10_TX0_VAL || cmn != C10_CMN0_DP_VAL)
> > > > > > + drm_warn(>drm, "Unexpected tx: %x or cmn: %x for
> > > > > > phy:
> %c.\n",
> > > > > > +tx0, cmn, phy_name(phy));
> > > > >
> > > > > Shouldn't
> PHY_C10_VDR_CONTROL(1)/C10_VDR_CTRL_MSGBUS_ACCESS be
> > > > > cleared here?
> > > >
> > > > Usually this means that we are not accessing these values from the
> > > > register. Was this in the spec that we would need to clear it?
> > >
> > > It does get cleared at the end of intel_c10_pll_program(), at least
> > > from one of the PHY lanes, so was wondering why things are done
> > > differently here. Yes, the spec doesn't require clearing it, but
> > > then it should not be cleared at other places either (has related
> > > comments on this in follow-up reviews).
> >
> > To be consistent maybe we can clear this here as well.
>
> If there is no need for it, let's follow the spec and not clear it at
> any other spot either.
>
> >
> > >
> > > > > > +}
> > > > > > +
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/mtl: Fix Wa_16015201720 implementation
Sure Andi. Will be more cautious. Radhakrishna Sripada > -Original Message- > From: Andi Shyti > Sent: Thursday, March 9, 2023 3:09 PM > To: Sripada, Radhakrishna > Cc: Andi Shyti ; intel-gfx@lists.freedesktop.org; > De > Marchi, Lucas ; Roper, Matthew D > > Subject: Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/mtl: Fix Wa_16015201720 > implementation > > Hi Radhakrishna, > > > Since most of the comments aligned with Matt's suggestion pushed with > Matt's r-b. > > OK, but next time, please hold on a bit as I might also have had > disagreements on your answers or I want to see it tested again > with the new changes. > > It's not the case as I would have r-b it anyway and the changes > were trivial, but next time, please give it a bit more time until > all questions are answered. > > > Thanks you for the review. > > You're welcome :) > > Thanks, > Andi
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/mtl: Fix Wa_16015201720 implementation
Hi Andi,
> -Original Message-
> From: Andi Shyti
> Sent: Thursday, March 9, 2023 8:30 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org; De Marchi, Lucas
>
> Subject: Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/mtl: Fix Wa_16015201720
> implementation
>
> Hi Radhakrishna,
>
> On Wed, Mar 01, 2023 at 12:10:49PM -0800, Radhakrishna Sripada wrote:
> > The commit 2357f2b271ad ("drm/i915/mtl: Initial display workarounds")
> > extended the workaround Wa_16015201720 to MTL. However the registers
> > that the original WA implemented moved for MTL.
> >
> > Implement the workaround with the correct register.
> >
> > v3: Skip clock gating for pipe C, D DMC's and fix the title
> >
> > Fixes: 2357f2b271ad ("drm/i915/mtl: Initial display workarounds")
> > Cc: Matt Atwood
> > Cc: Lucas De Marchi
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 26 +++-
> > drivers/gpu/drm/i915/i915_reg.h | 10 ++---
> > 2 files changed, 28 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> > index f70ada2357dc..b4283cf319f2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > @@ -389,15 +389,12 @@ static void disable_all_event_handlers(struct
> drm_i915_private *i915)
> > }
> > }
> >
> > -static void pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool
> enable)
> > +static void adlp_pipedmc_clock_gating_wa(struct drm_i915_private *i915,
> bool enable)
> > {
> > enum pipe pipe;
> >
> > - if (DISPLAY_VER(i915) < 13)
> > - return;
> > -
>
> Why is this not needed anyomore?
With the check below while calling the function the check here becomes
redundant.
>
> > /*
> > -* Wa_16015201720:adl-p,dg2, mtl
> > +* Wa_16015201720:adl-p,dg2
> > * The WA requires clock gating to be disabled all the time
> > * for pipe A and B.
> > * For pipe C and D clock gating needs to be disabled only
> > @@ -413,6 +410,25 @@ static void pipedmc_clock_gating_wa(struct
> drm_i915_private *i915, bool enable)
> > PIPEDMC_GATING_DIS, 0);
> > }
> >
> > +static void mtl_pipedmc_clock_gating_wa(struct drm_i915_private *i915)
> > +{
> > + /*
> > +* Wa_16015201720
> > +* The WA requires clock gating to be disabled all the time
> > +* for pipe A and B.
> > +*/
> > + intel_de_rmw(i915, GEN9_CLKGATE_DIS_0, 0,
> > +MTL_PIPEDMC_GATING_DIS_A |
> MTL_PIPEDMC_GATING_DIS_B);
> > +}
> > +
> > +static void pipedmc_clock_gating_wa(struct drm_i915_private *i915, bool
> enable)
> > +{
> > + if (DISPLAY_VER(i915) >= 14 && enable)
> > + return mtl_pipedmc_clock_gating_wa(i915);
> > + else if (DISPLAY_VER(i915) == 13)
> > + return adlp_pipedmc_clock_gating_wa(i915, enable);
>
> don't you get an error here? Please don't return anything.
Addressed based on review comments from Matt Roper.
>
> > +}
> > +
> > void intel_dmc_enable_pipe(struct drm_i915_private *i915, enum pipe pipe)
> > {
> > enum intel_dmc_id dmc_id = PIPE_TO_DMC_ID(pipe);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > index c1efa655fb68..7c9ac5b43831 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1794,9 +1794,13 @@
> > * GEN9 clock gating regs
> > */
> > #define GEN9_CLKGATE_DIS_0 _MMIO(0x46530)
> > -#define DARBF_GATING_DIS (1 << 27)
> > -#define PWM2_GATING_DIS (1 << 14)
> > -#define PWM1_GATING_DIS (1 << 13)
> > +#define DARBF_GATING_DIS REG_BIT(27)
> > +#define MTL_PIPEDMC_GATING_DIS_A REG_BIT(15)
> > +#define MTL_PIPEDMC_GATING_DIS_B REG_BIT(14)
>
> you could eventually use a GENMASK here and it can be:
We may have to play with individual pipes here and b-spec defines them as
Individual bits. So leaving them as is.
>
> #define MTL_PIPEDMC_GATING_DIS REG_GENMASK(15, 14)
>
> > +#define PWM2_GATING_DIS REG_BIT(14)
> > +#define MTL_PIPEDMC_GATING_DIS_C REG_BIT(13)
>
> Is this needed?
Below
>
> > +#define PWM1_GATING_DIS REG_BIT(13)
> > +#define MTL_PIPEDMC_GATING_DIS_D REG_BIT(12)
>
> Is this needed?
Removed MTL_PIPEDMC_GATING_DIS_D and MTL_PIPEDMC_GATING_DIS_C
Based on review feedback from MattR.
Since most of the comments aligned with Matt's suggestion pushed with Matt's
r-b.
Thanks you for the review.
-Radhakrishna Sripada
>
> Thanks,
> Andi
>
> > #define GEN9_CLKGATE_DIS_3 _MMIO(0x46538)
> > #define TGL_VRH_GATING_DIS REG_BIT(31)
> > --
> > 2.34.1
Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/fbdev: lock the fbdev obj before vma pin
Thank you for the Review. Pushed.
-Radhakrishna Sripada
> -Original Message-
> From: Andi Shyti
> Sent: Thursday, March 9, 2023 9:18 AM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org; Auld, Matthew ;
> Wilson, Chris P
> Subject: Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/fbdev: lock the fbdev obj
> before vma pin
>
> Hi Radhakrishna,
>
> On Wed, Mar 01, 2023 at 12:10:52PM -0800, Radhakrishna Sripada wrote:
> > From: Tejas Upadhyay
> >
> > lock the fbdev obj before calling into
> > i915_vma_pin_iomap(). This helps to solve below :
> >
> > <7>[ 93.563308] i915 :00:02.0: [drm:intelfb_create [i915]] no BIOS fb,
> allocating a new one
> > <4>[ 93.581844] [ cut here ]
> > <4>[ 93.581855] WARNING: CPU: 12 PID: 625 at
> drivers/gpu/drm/i915/gem/i915_gem_pages.c:424
> i915_gem_object_pin_map+0x152/0x1c0 [i915]
> >
> > Fixes: f0b6b01b3efe ("drm/i915: Add ww context to intel_dpt_pin, v2.")
> > Cc: Chris Wilson
> > Cc: Matthew Auld
> > Cc: Maarten Lankhorst
> > Signed-off-by: Tejas Upadhyay
> > Signed-off-by: Radhakrishna Sripada
>
> Reviewed-by: Andi Shyti
>
> Andi
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/display/mtl: Program latch to phy reset
Thank you for the Review. Pushed. -Radhakrishna Sripada > -Original Message- > From: Andi Shyti > Sent: Thursday, March 9, 2023 9:29 AM > To: Sripada, Radhakrishna > Cc: intel-gfx@lists.freedesktop.org; Roper, Matthew D > > Subject: Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/display/mtl: Program latch to > phy reset > > Hi, > > On Wed, Mar 01, 2023 at 12:10:53PM -0800, Radhakrishna Sripada wrote: > > From: José Roberto de Souza > > > > Latch reset of phys during DC9 and when driver is unloaded to avoid > > phy reset. > > > > Specification ask us to program it closer to the step that enables > > DC9 in DC_STATE_EN but doing this way allow us to sanitize the phy > > latch during driver load. > > > > BSpec: 49197 > > Reviewed-by: Matt Roper > > Signed-off-by: José Roberto de Souza > > Signed-off-by: Radhakrishna Sripada > > Reviewed-by: Andi Shyti > > Thanks, > Andi
Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/mtl: make IRQ reset and postinstall multi-gt aware
+Daniele,
Hi Matt,
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, March 6, 2023 2:55 PM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org; De Marchi, Lucas
> ; Zanoni, Paulo R
> Subject: Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/mtl: make IRQ reset and
> postinstall multi-gt aware
>
> On Wed, Mar 01, 2023 at 12:10:51PM -0800, Radhakrishna Sripada wrote:
> > Irq reset and post install are to be made multi-gt aware for the
> > interrupts to work for the media tile on Meteorlake. Iterate through
> > all the gts to process irq reset for each gt.
>
> I think I mentioned on the previous version, but this isn't right. MTL
> does not have separate interrupt registers for each GT the way
> multi-tile platforms like PVC do. The GT interrupt registers you're
> handling here are in the sgunit so there's only a single copy of them;
> iterating over them multiple times in a row doesn't accomplish anything.
>
> The media engine bits are still on the same registers as the primary GT
> and the GSC and media GuC are new additional bits that need to be
> handled. The necessary handling for the GSC and media GuC should have
> already landed in a187f13d51fa ("drm/i915/guc: handle interrupts from
> media GuC") and c07ee636901d ("drm/i915/mtl: add GSC CS interrupt
> support"), but if there's another bit that was missed somewhere (or if
> we were doing something like looking at the wrong intel_gt's engine mask
> somewhere), that would need to be addressed directly rather than just
> looping over the same IRQ registers multiple times.
This patch is needed to handle media interrupts. Without this patch we observed
GuC not loading/communication errors on media gt.
My understanding is that Sgunit is embedded into the SAMedia block and hence
need
To be iterated over separately.
Daniele,
Can you confirm if that is accurate.
Thanks,
RK
>
>
> Matt
>
> >
> > Based on original version by Paulo and Tvrtko
> >
> > Cc: Paulo Zanoni
> > Cc: Tvrtko Ursulin
> > Reviewed-by: Lucas De Marchi
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 30 ++
> > 1 file changed, 18 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 417c981e4968..9377f59c1ac2 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2759,16 +2759,19 @@ static void gen11_irq_reset(struct
> drm_i915_private *dev_priv)
> >
> > static void dg1_irq_reset(struct drm_i915_private *dev_priv)
> > {
> > - struct intel_gt *gt = to_gt(dev_priv);
> > - struct intel_uncore *uncore = gt->uncore;
> > + struct intel_gt *gt;
> > + unsigned int i;
> >
> > dg1_master_intr_disable(dev_priv->uncore.regs);
> >
> > - gen11_gt_irq_reset(gt);
> > - gen11_display_irq_reset(dev_priv);
> > + for_each_gt(gt, dev_priv, i) {
> > + gen11_gt_irq_reset(gt);
> >
> > - GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> > - GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> > + GEN3_IRQ_RESET(gt->uncore, GEN11_GU_MISC_);
> > + GEN3_IRQ_RESET(gt->uncore, GEN8_PCU_);
> > + }
> > +
> > + gen11_display_irq_reset(dev_priv);
> > }
> >
> > void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
> > @@ -3422,13 +3425,16 @@ static void gen11_irq_postinstall(struct
> drm_i915_private *dev_priv)
> >
> > static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
> > {
> > - struct intel_gt *gt = to_gt(dev_priv);
> > - struct intel_uncore *uncore = gt->uncore;
> > u32 gu_misc_masked = GEN11_GU_MISC_GSE;
> > + struct intel_gt *gt;
> > + unsigned int i;
> >
> > - gen11_gt_irq_postinstall(gt);
> > + for_each_gt(gt, dev_priv, i) {
> > + gen11_gt_irq_postinstall(gt);
> >
> > - GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked,
> gu_misc_masked);
> > + GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_,
> ~gu_misc_masked,
> > + gu_misc_masked);
> > + }
> >
> > if (HAS_DISPLAY(dev_priv)) {
> > icp_irq_postinstall(dev_priv);
> > @@ -3437,8 +3443,8 @@ static void dg1_irq_postinstall(struct
> drm_i915_private *dev_priv)
> >GEN11_DISPLAY_IRQ_ENABLE);
> > }
> >
> > - dg1_master_intr_enable(uncore->regs);
> > - intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
> > + dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
> > + intel_uncore_posting_read(to_gt(dev_priv)->uncore,
> DG1_MSTR_TILE_INTR);
> > }
> >
> > static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
> > --
> > 2.34.1
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gt: Create per-tile debugfs files
> -Original Message-
> From: Andi Shyti
> Sent: Friday, March 3, 2023 7:24 PM
> To: Sripada, Radhakrishna
> Cc: Andi Shyti ; intel-gfx@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org; Tvrtko Ursulin ;
> Andi Shyti ; Patelczyk, Maciej
> ; Wajdeczko, Michal
>
> Subject: Re: [PATCH v2 1/2] drm/i915/gt: Create per-tile debugfs files
>
> On Wed, Mar 01, 2023 at 09:35:33PM +, Sripada, Radhakrishna wrote:
> > I am not sure if Tiles is appropriate usage here. Since MTL does not have
> > the
> concept of tiles.
> > Shouldn't we be using gt instead of tile in our usage?
> >
> > With s/tile/gt/g,
> > Reviewed-by: Radhakrishna Sripada
>
> Just one question... you reviewed twice Patch number 1. Did you
> mean to review patch 1 and patch 2?
This was for Patch1 itself. I did not include s/tile/gt/g during the first time
I gave r-b
hence added that with new r-b.
-RK
>
> Thanks,
> Andi
>
> >
> > > -Original Message-
> > > From: dri-devel On Behalf Of
> Andi
> > > Shyti
> > > Sent: Wednesday, March 1, 2023 3:03 AM
> > > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> > > Cc: Tvrtko Ursulin ; Andi Shyti
> > > ; Patelczyk, Maciej ; Andi
> > > Shyti ; Wajdeczko, Michal
> > >
> > > Subject: [PATCH v2 1/2] drm/i915/gt: Create per-tile debugfs files
> > >
> > > To support multi-GT configurations, we need to generate
> > > independent debug files for each GT.
> > >
> > > To achieve this create a separate directory for each GT under the
> > > debugfs directory. For instance, in a system with two tiles, the
> > > debugfs structure would look like this:
> > >
> > > /sys/kernel/debug/dri
> > > └── 0
> > > ├── gt0
> > > │ ├── drpc
> > > │ ├── engines
> > > │ ├── forcewake
> > > │ ├── frequency
> > > │ └── rps_boost
> > > └── gt1
> > > : ├── drpc
> > > : ├── engines
> > > : ├── forcewake
> > > ├── frequency
> > > └── rps_boost
> > >
> > > Signed-off-by: Andi Shyti
> > > Cc: Tvrtko Ursulin
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 4 +++-
> > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 5 -
> > > drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 ++
> > > 4 files changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > > b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > > index 5fc2df01aa0df..4dc23b8d3aa2d 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> > > @@ -83,11 +83,13 @@ static void gt_debugfs_register(struct intel_gt *gt,
> > > struct dentry *root)
> > > void intel_gt_debugfs_register(struct intel_gt *gt)
> > > {
> > > struct dentry *root;
> > > + char gtname[4];
> > >
> > > if (!gt->i915->drm.primary->debugfs_root)
> > > return;
> > >
> > > - root = debugfs_create_dir("gt", gt->i915->drm.primary->debugfs_root);
> > > + snprintf(gtname, sizeof(gtname), "gt%u", gt->info.id);
> > > + root = debugfs_create_dir(gtname, gt->i915->drm.primary-
> > > >debugfs_root);
> > > if (IS_ERR(root))
> > > return;
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > index bb4dfe707a7d0..e46aac1a41e6d 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > @@ -42,6 +42,8 @@ struct intel_guc {
> > > /** @capture: the error-state-capture module's data and objects */
> > > struct intel_guc_state_capture *capture;
> > >
> > > + struct dentry *dbgfs_node;
> > > +
> > > /** @sched_engine: Global engine used to submit requests to GuC */
> > > struct i915_sched_engine *sched_engine;
> > > /**
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
Re: [Intel-gfx] [PATCH v4 04/22] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
Hi Mika,
> -Original Message-
> From: Kahola, Mika
> Sent: Friday, February 24, 2023 2:14 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sripada, Radhakrishna ; Deak, Imre
> ; Shankar, Uma ; Kahola,
> Mika
> Subject: [PATCH v4 04/22] drm/i915/mtl: Add Support for C10 PHY message bus
> and pll programming
>
> From: Radhakrishna Sripada
>
> XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
> has a dedicated PIPE 5.2 Message bus for configuration. This message
> bus is used to configure the phy internal registers.
>
> XELPDP has C10 phys to drive output to the EDP and the native output
> from the display engine. Add structures, programming hardware state
> readout logic. Port clock calculations are similar to DG2. Use the DG2
> formulae to calculate the port clock but use the relevant pll signals.
> Note: PHY lane 0 is always used for PLL programming.
>
> Add sequences for C10 phy enable/disable phy lane reset,
> powerdown change sequence and phy lane programming.
>
> Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636
>
> v2: Squash patches related to C10 phy message bus and pll
> programming support (Jani)
> Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani)
> Move macro definitions (Jani)
> DP rates as separate patch (Jani)
> Spin out xelpdp register definitions into a separate file (Jani)
> Replace macro to select registers based on phy lane with
> function calls (Jani)
> Fix styling issues (Jani)
> Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas)
> v3: Move clear request flag into try-loop
> v4: On PHY idle change drm_err_once() as drm_dbg_kms() (Jani)
> use __intel_de_wait_for_register() instead of __intel_wait_for_register
> and uncomment intel_uncore.h (Jani)
> Add DP-alt support for PHY lane programming (Khaled)
>
> Cc: Imre Deak
> Cc: Uma Shankar
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/Makefile |1 +
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 1120 +
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 43 +
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 34 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 22 +-
> .../drm/i915/display/intel_display_power.c|3 +-
> .../i915/display/intel_display_power_well.c |2 +-
> .../drm/i915/display/intel_display_types.h|6 +
> drivers/gpu/drm/i915/display/intel_dpll.c | 22 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
> .../drm/i915/display/intel_modeset_verify.c |2 +
> drivers/gpu/drm/i915/i915_reg.h |5 +
> drivers/gpu/drm/i915/i915_reg_defs.h | 57 +
> 13 files changed, 1314 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b2f91a1f8268..b04395472437 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -294,6 +294,7 @@ i915-y += \
> display/icl_dsi.o \
> display/intel_backlight.o \
> display/intel_crt.o \
> + display/intel_cx0_phy.o \
> display/intel_ddi.o \
> display/intel_ddi_buf_trans.o \
> display/intel_display_trace.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> new file mode 100644
> index ..dce55f0ed5e1
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -0,0 +1,1120 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include "i915_reg.h"
> +#include "intel_cx0_phy.h"
> +#include "intel_cx0_phy_regs.h"
> +#include "intel_de.h"
> +#include "intel_display_types.h"
> +#include "intel_dp.h"
> +#include "intel_panel.h"
> +#include "intel_tc.h"
> +
> +bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
> +{
> + if (IS_METEORLAKE(dev_priv) && (phy < PHY_C))
> + return true;
> +
> + return false;
> +}
> +
> +static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port
> port,
> int lane)
> +{
> + enum phy phy = intel_port_to_phy(i915, port);
> +
> + /* Bring the phy to idle. */
> + intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane-1),
> +XELPDP_PORT_M2P_TRANSACTION_RESET);
> +
>
Re: [Intel-gfx] [PATCH v3 06/22] drm/i915/mtl: Add vswing programming for C10 phys
Hi Mika,
> -Original Message-
> From: Kahola, Mika
> Sent: Thursday, February 23, 2023 5:40 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sripada, Radhakrishna ; Deak, Imre
> ; Shankar, Uma ; Taylor,
> Clinton A ; Kahola, Mika
> Subject: [PATCH v3 06/22] drm/i915/mtl: Add vswing programming for C10 phys
>
> From: Radhakrishna Sripada
>
> C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
> Program the levels directly to the fields in the VDR Registers.
>
> Bspec: 65449
>
> v2: From table "C10: Tx EQ settings for DP 1.4x" it shows level 1
> and preemphasis 1 instead of two times of level 1 preemphasis 0.
> Fix this in the driver code as well.
> v3: VSwing update (Clint)
>
> Cc: Imre Deak
> Cc: Uma Shankar
> Signed-off-by: Clint Taylor
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 140 --
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 14 ++
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
> .../drm/i915/display/intel_ddi_buf_trans.c| 36 -
> .../drm/i915/display/intel_ddi_buf_trans.h| 6 +
> .../i915/display/intel_display_power_map.c| 1 +
> 7 files changed, 192 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index c73d2bc3e1a8..3d61afbe7bdb 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -6,11 +6,15 @@
> #include "i915_reg.h"
> #include "intel_cx0_phy.h"
> #include "intel_cx0_phy_regs.h"
> +#include "intel_ddi.h"
> +#include "intel_ddi_buf_trans.h"
> #include "intel_de.h"
> #include "intel_display_types.h"
> #include "intel_dp.h"
> #include "intel_panel.h"
> #include "intel_tc.h"
> +#include "intel_psr.h"
> +#include "intel_uncore.h"
>
> bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
> {
> @@ -20,6 +24,15 @@ bool intel_is_c10phy(struct drm_i915_private *dev_priv,
> enum phy phy)
> return false;
> }
>
> +static void
> +assert_dc_off(struct drm_i915_private *i915)
> +{
> + bool enabled;
> +
> + enabled = intel_display_power_is_enabled(i915,
> POWER_DOMAIN_DC_OFF);
> + drm_WARN_ON(>drm, !enabled);
> +}
> +
> static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port
> port,
> int lane)
> {
> enum phy phy = intel_port_to_phy(i915, port);
> @@ -112,6 +125,8 @@ static u8 intel_cx0_read(struct drm_i915_private *i915,
> enum port port,
> int i, status = 0;
> u32 val;
>
> + assert_dc_off(i915);
> +
> for (i = 0; i < 3; i++) {
> status = __intel_cx0_read(i915, port, lane, addr, );
>
> @@ -194,6 +209,8 @@ static void __intel_cx0_write(struct drm_i915_private
> *i915, enum port port,
> enum phy phy = intel_port_to_phy(i915, port);
> int i, status;
>
> + assert_dc_off(i915);
> +
> for (i = 0; i < 3; i++) {
> status = __intel_cx0_write_once(i915, port, lane, addr, data,
> committed);
>
> @@ -241,6 +258,89 @@ static void intel_cx0_rmw(struct drm_i915_private
> *i915, enum port port,
> }
> }
>
> +/*
> + * Prepare HW for CX0 phy transactions.
> + *
> + * It is required that PSR and DC5/6 are disabled before any CX0 message
> + * bus transaction is executed.
> + */
> +static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder
> *encoder)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + intel_psr_pause(intel_dp);
> + return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
> +}
> +
> +static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder,
> intel_wakeref_t wakeref)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + intel_psr_resume(intel_dp);
> + intel_display_power_put(i915, POWER_DOMAIN_DC_OFF, wakeref);
> +}
> +
> +void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_di
Re: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM DEMAND
> -Original Message-
> From: Intel-gfx On Behalf Of Kahola,
> Mika
> Sent: Thursday, March 2, 2023 1:40 AM
> To: Murthy, Arun R ; intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; De Marchi, Lucas
>
> Subject: Re: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> DEMAND
>
> > -Original Message-
> > From: Murthy, Arun R
> > Sent: Thursday, March 2, 2023 10:50 AM
> > To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> > Cc: De Marchi, Lucas ; Roper, Matthew D
> >
> > Subject: RE: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> > DEMAND
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf Of
> > > Mika Kahola
> > > Sent: Friday, February 24, 2023 3:44 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: De Marchi, Lucas ; Roper, Matthew D
> > >
> > > Subject: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> > > DEMAND
> > >
> > > Display14 introduces a new way to instruct the PUnit with power and
> > > bandwidth requirements of DE. Add the functionality to program the
> > > registers and handle waits using interrupts.
> > > The current wait time for timeouts is programmed for 10 msecs to
> > > factor in the worst case scenarios. Changes made to use REG_BIT for a
> > > register that we touched(GEN8_DE_MISC_IER _MMIO).
> > >
> > > v2:
> > > - Removed repeated definition of dbuf, which has been moved to struct
> > > intel_display. (Gustavo)
> > > - s/dev_priv->dbuf/dev_priv->display.dbuf/ (Gustavo)
> > >
> > > Bspec: 66451, 64636, 64602, 64603
> > > Cc: Matt Atwood
> > > Cc: Matt Roper
> > > Cc: Lucas De Marchi
> > > Cc: Gustavo Sousa
> > > Signed-off-by: José Roberto de Souza
> > > Signed-off-by: Radhakrishna Sripada
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-
> 8-
> > > mika.kah...@intel.com
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bw.c | 4 +-
> > > drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> > > drivers/gpu/drm/i915/display/intel_display.c | 14 +
> > > .../drm/i915/display/intel_display_power.c| 8 +
> > > drivers/gpu/drm/i915/i915_drv.h | 6 +
> > > drivers/gpu/drm/i915/i915_irq.c | 22 +-
> > > drivers/gpu/drm/i915/i915_reg.h | 33 +-
> > > drivers/gpu/drm/i915/intel_pm.c | 286 ++
> > > drivers/gpu/drm/i915/intel_pm.h | 35 +++
> > > 9 files changed, 405 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > > b/drivers/gpu/drm/i915/display/intel_bw.c
> > > index 202321ffbe2a..87c20bf52123 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > @@ -746,8 +746,8 @@ static unsigned int
> > > intel_bw_num_active_planes(struct drm_i915_private *dev_priv
> > > return num_active_planes;
> > > }
> > >
> > > -static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > > -const struct intel_bw_state *bw_state)
> > > +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > > + const struct intel_bw_state *bw_state)
> > > {
> > > unsigned int data_rate = 0;
> > > enum pipe pipe;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > index f20292143745..17fc0b61db04 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > @@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private
> > > *dev_priv); int intel_bw_atomic_check(struct intel_atomic_state
> > > *state); void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> > > const struct intel_crtc_state *crtc_state);
> > > +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > > + const struct intel_bw_state *bw_state);
> > > int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> > > u32 points_mask);
> > > int intel_bw_calc_min_cdclk(struct intel_atomic_state *state, diff
> > > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 8030968e7008..676bf512b9ce 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -959,6 +959,9 @@ intel_get_crtc_new_encoder(const struct
> > > intel_atomic_state *state,
> > > num_encoders++;
> > > }
> > >
> > > + if (!encoder)
> > > + return NULL;
> > > +
> > > drm_WARN(encoder->base.dev, num_encoders != 1,
> > >"%d encoders for pipe %c\n",
> > >num_encoders, pipe_name(master_crtc->pipe)); @@ -
> > > 6823,6 +6826,10 @@ int intel_atomic_check(struct drm_device *dev,
> > > ret = intel_modeset_calc_cdclk(state);
> > > if (ret)
> > >
Re: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM DEMAND
Hi Mika,
> -Original Message-
> From: Kahola, Mika
> Sent: Friday, February 24, 2023 2:14 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika ; Atwood, Matthew S
> ; Roper, Matthew D
> ; De Marchi, Lucas ;
> Sousa, Gustavo ; Souza, Jose
> ; Sripada, Radhakrishna
>
> Subject: [PATCH v4 07/22] drm/i915/mtl: Add support for PM DEMAND
>
> Display14 introduces a new way to instruct the PUnit with
> power and bandwidth requirements of DE. Add the functionality
> to program the registers and handle waits using interrupts.
> The current wait time for timeouts is programmed for 10 msecs to
> factor in the worst case scenarios. Changes made to use REG_BIT
> for a register that we touched(GEN8_DE_MISC_IER _MMIO).
>
> v2:
> - Removed repeated definition of dbuf, which has been moved to struct
> intel_display. (Gustavo)
> - s/dev_priv->dbuf/dev_priv->display.dbuf/ (Gustavo)
>
> Bspec: 66451, 64636, 64602, 64603
> Cc: Matt Atwood
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Cc: Gustavo Sousa
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Radhakrishna Sripada
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-8-
> mika.kah...@intel.com
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 4 +-
> drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> drivers/gpu/drm/i915/display/intel_display.c | 14 +
> .../drm/i915/display/intel_display_power.c| 8 +
> drivers/gpu/drm/i915/i915_drv.h | 6 +
> drivers/gpu/drm/i915/i915_irq.c | 22 +-
> drivers/gpu/drm/i915/i915_reg.h | 33 +-
> drivers/gpu/drm/i915/intel_pm.c | 286 ++
> drivers/gpu/drm/i915/intel_pm.h | 35 +++
> 9 files changed, 405 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 202321ffbe2a..87c20bf52123 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -746,8 +746,8 @@ static unsigned int intel_bw_num_active_planes(struct
> drm_i915_private *dev_priv
> return num_active_planes;
> }
>
> -static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> -const struct intel_bw_state *bw_state)
> +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> + const struct intel_bw_state *bw_state)
> {
> unsigned int data_rate = 0;
> enum pipe pipe;
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index f20292143745..17fc0b61db04 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
> int intel_bw_atomic_check(struct intel_atomic_state *state);
> void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> const struct intel_crtc_state *crtc_state);
> +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> + const struct intel_bw_state *bw_state);
> int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> u32 points_mask);
> int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8030968e7008..676bf512b9ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -959,6 +959,9 @@ intel_get_crtc_new_encoder(const struct
> intel_atomic_state *state,
> num_encoders++;
> }
>
> + if (!encoder)
> + return NULL;
> +
> drm_WARN(encoder->base.dev, num_encoders != 1,
>"%d encoders for pipe %c\n",
>num_encoders, pipe_name(master_crtc->pipe));
> @@ -6823,6 +6826,10 @@ int intel_atomic_check(struct drm_device *dev,
> ret = intel_modeset_calc_cdclk(state);
> if (ret)
> return ret;
> +
> + ret = intel_pmdemand_atomic_check(state);
> + if (ret)
> + goto fail;
> }
>
> ret = intel_atomic_check_crtcs(state);
> @@ -7439,6 +7446,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> }
>
> intel_sagv_pre_plane_update(state);
> + intel_pmdemand_pre_plane_update(state);
>
> /* Complete the
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gt: Create per-tile debugfs files
I am not sure if Tiles is appropriate usage here. Since MTL does not have the
concept of tiles.
Shouldn't we be using gt instead of tile in our usage?
With s/tile/gt/g,
Reviewed-by: Radhakrishna Sripada
> -Original Message-
> From: dri-devel On Behalf Of Andi
> Shyti
> Sent: Wednesday, March 1, 2023 3:03 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Tvrtko Ursulin ; Andi Shyti
> ; Patelczyk, Maciej ; Andi
> Shyti ; Wajdeczko, Michal
>
> Subject: [PATCH v2 1/2] drm/i915/gt: Create per-tile debugfs files
>
> To support multi-GT configurations, we need to generate
> independent debug files for each GT.
>
> To achieve this create a separate directory for each GT under the
> debugfs directory. For instance, in a system with two tiles, the
> debugfs structure would look like this:
>
> /sys/kernel/debug/dri
> └── 0
> ├── gt0
> │ ├── drpc
> │ ├── engines
> │ ├── forcewake
> │ ├── frequency
> │ └── rps_boost
> └── gt1
> : ├── drpc
> : ├── engines
> : ├── forcewake
> ├── frequency
> └── rps_boost
>
> Signed-off-by: Andi Shyti
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 4 +++-
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 5 -
> drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 ++
> 4 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> index 5fc2df01aa0df..4dc23b8d3aa2d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> @@ -83,11 +83,13 @@ static void gt_debugfs_register(struct intel_gt *gt,
> struct dentry *root)
> void intel_gt_debugfs_register(struct intel_gt *gt)
> {
> struct dentry *root;
> + char gtname[4];
>
> if (!gt->i915->drm.primary->debugfs_root)
> return;
>
> - root = debugfs_create_dir("gt", gt->i915->drm.primary->debugfs_root);
> + snprintf(gtname, sizeof(gtname), "gt%u", gt->info.id);
> + root = debugfs_create_dir(gtname, gt->i915->drm.primary-
> >debugfs_root);
> if (IS_ERR(root))
> return;
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index bb4dfe707a7d0..e46aac1a41e6d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -42,6 +42,8 @@ struct intel_guc {
> /** @capture: the error-state-capture module's data and objects */
> struct intel_guc_state_capture *capture;
>
> + struct dentry *dbgfs_node;
> +
> /** @sched_engine: Global engine used to submit requests to GuC */
> struct i915_sched_engine *sched_engine;
> /**
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index 195db8c9d4200..55bc8b55fbc05 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -542,8 +542,11 @@ static int guc_log_relay_create(struct intel_guc_log
> *log)
>*/
> n_subbufs = 8;
>
> + if (!guc->dbgfs_node)
> + return -ENOENT;
> +
> guc_log_relay_chan = relay_open("guc_log",
> - i915->drm.primary->debugfs_root,
> + guc->dbgfs_node,
> subbuf_size, n_subbufs,
> _callbacks, i915);
> if (!guc_log_relay_chan) {
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> index 284d6fbc2d08c..2f93cc4e408a8 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> @@ -54,6 +54,8 @@ void intel_uc_debugfs_register(struct intel_uc *uc, struct
> dentry *gt_root)
> if (IS_ERR(root))
> return;
>
> + uc->guc.dbgfs_node = root;
> +
> intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), uc);
>
> intel_guc_debugfs_register(>guc, root);
> --
> 2.39.1
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/gt: Create per-tile debugfs files
> -Original Message-
> From: dri-devel On Behalf Of Andi
> Shyti
> Sent: Wednesday, March 1, 2023 3:03 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Tvrtko Ursulin ; Andi Shyti
> ; Patelczyk, Maciej ; Andi
> Shyti ; Wajdeczko, Michal
>
> Subject: [PATCH v2 1/2] drm/i915/gt: Create per-tile debugfs files
>
> To support multi-GT configurations, we need to generate
> independent debug files for each GT.
>
> To achieve this create a separate directory for each GT under the
> debugfs directory. For instance, in a system with two tiles, the
> debugfs structure would look like this:
>
> /sys/kernel/debug/dri
> └── 0
> ├── gt0
> │ ├── drpc
> │ ├── engines
> │ ├── forcewake
> │ ├── frequency
> │ └── rps_boost
> └── gt1
> : ├── drpc
> : ├── engines
> : ├── forcewake
> ├── frequency
> └── rps_boost
>
> Signed-off-by: Andi Shyti
> Cc: Tvrtko Ursulin
LGTM,
Reviewed-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 4 +++-
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 5 -
> drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 ++
> 4 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> index 5fc2df01aa0df..4dc23b8d3aa2d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> @@ -83,11 +83,13 @@ static void gt_debugfs_register(struct intel_gt *gt,
> struct dentry *root)
> void intel_gt_debugfs_register(struct intel_gt *gt)
> {
> struct dentry *root;
> + char gtname[4];
>
> if (!gt->i915->drm.primary->debugfs_root)
> return;
>
> - root = debugfs_create_dir("gt", gt->i915->drm.primary->debugfs_root);
> + snprintf(gtname, sizeof(gtname), "gt%u", gt->info.id);
> + root = debugfs_create_dir(gtname, gt->i915->drm.primary-
> >debugfs_root);
> if (IS_ERR(root))
> return;
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index bb4dfe707a7d0..e46aac1a41e6d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -42,6 +42,8 @@ struct intel_guc {
> /** @capture: the error-state-capture module's data and objects */
> struct intel_guc_state_capture *capture;
>
> + struct dentry *dbgfs_node;
> +
> /** @sched_engine: Global engine used to submit requests to GuC */
> struct i915_sched_engine *sched_engine;
> /**
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index 195db8c9d4200..55bc8b55fbc05 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -542,8 +542,11 @@ static int guc_log_relay_create(struct intel_guc_log
> *log)
>*/
> n_subbufs = 8;
>
> + if (!guc->dbgfs_node)
> + return -ENOENT;
> +
> guc_log_relay_chan = relay_open("guc_log",
> - i915->drm.primary->debugfs_root,
> + guc->dbgfs_node,
> subbuf_size, n_subbufs,
> _callbacks, i915);
> if (!guc_log_relay_chan) {
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> index 284d6fbc2d08c..2f93cc4e408a8 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> @@ -54,6 +54,8 @@ void intel_uc_debugfs_register(struct intel_uc *uc, struct
> dentry *gt_root)
> if (IS_ERR(root))
> return;
>
> + uc->guc.dbgfs_node = root;
> +
> intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), uc);
>
> intel_guc_debugfs_register(>guc, root);
> --
> 2.39.1
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gt: generate per tile debugfs files
This patch can be ignored. As the original Author submitted the series here
https://patchwork.freedesktop.org/series/114510/
- Radhakrishna(RK) Sripada
> -Original Message-
> From: Sripada, Radhakrishna
> Sent: Wednesday, March 1, 2023 12:11 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shyti, Andi ; Ursulin, Tvrtko
> ; Sripada, Radhakrishna
>
> Subject: [PATCH v3 2/5] drm/i915/gt: generate per tile debugfs files
>
> From: Andi Shyti
>
> In the view of multi-gt we want independent per gt debug files.
>
> In debugfs create gt0/ gt1/ ... gtN/ for tile related files. In 4
> tiles, the debugfs would be structured as follows:
>
> /sys/kernel/debug/dri
> └── 0
> ├── gt0
> │ ├── drpc
> │ ├── engines
> │ ├── forcewake
> │ ├── frequency
> │ └── rps_boost
> ├── gt1
> │ ├── drpc
> │ ├── engines
> │ ├── forcewake
> │ ├── frequency
> │ └── rps_boost
> ├── gt2
> │ ├── drpc
> │ ├── engines
> │ ├── forcewake
> │ ├── frequency
> │ └── rps_boost
> └─- gt3
> : ├── drpc
> : ├── engines
> : ├── forcewake
> ├── frequency
> └── rps_boost
>
> v2: Fix the missed assignment dbgfs_node
>
> Cc: Tvrtko Ursulin
> Signed-off-by: Andi Shyti
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 4 +++-
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 5 -
> drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 ++
> 4 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> index 5fc2df01aa0d..4dc23b8d3aa2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> @@ -83,11 +83,13 @@ static void gt_debugfs_register(struct intel_gt *gt,
> struct dentry *root)
> void intel_gt_debugfs_register(struct intel_gt *gt)
> {
> struct dentry *root;
> + char gtname[4];
>
> if (!gt->i915->drm.primary->debugfs_root)
> return;
>
> - root = debugfs_create_dir("gt", gt->i915->drm.primary->debugfs_root);
> + snprintf(gtname, sizeof(gtname), "gt%u", gt->info.id);
> + root = debugfs_create_dir(gtname, gt->i915->drm.primary-
> >debugfs_root);
> if (IS_ERR(root))
> return;
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index bb4dfe707a7d..e46aac1a41e6 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -42,6 +42,8 @@ struct intel_guc {
> /** @capture: the error-state-capture module's data and objects */
> struct intel_guc_state_capture *capture;
>
> + struct dentry *dbgfs_node;
> +
> /** @sched_engine: Global engine used to submit requests to GuC */
> struct i915_sched_engine *sched_engine;
> /**
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index 195db8c9d420..55bc8b55fbc0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -542,8 +542,11 @@ static int guc_log_relay_create(struct intel_guc_log
> *log)
>*/
> n_subbufs = 8;
>
> + if (!guc->dbgfs_node)
> + return -ENOENT;
> +
> guc_log_relay_chan = relay_open("guc_log",
> - i915->drm.primary->debugfs_root,
> + guc->dbgfs_node,
> subbuf_size, n_subbufs,
> _callbacks, i915);
> if (!guc_log_relay_chan) {
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> index 284d6fbc2d08..2f93cc4e408a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
> @@ -54,6 +54,8 @@ void intel_uc_debugfs_register(struct intel_uc *uc, struct
> dentry *gt_root)
> if (IS_ERR(root))
> return;
>
> + uc->guc.dbgfs_node = root;
> +
> intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), uc);
>
> intel_guc_debugfs_register(>guc, root);
> --
> 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/xelpmp: Consider GSI offset when doing MCR lookups
> -Original Message-
> From: dri-devel On Behalf Of Matt
> Roper
> Sent: Monday, February 13, 2023 4:19 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Subject: [PATCH] drm/i915/xelpmp: Consider GSI offset when doing MCR
> lookups
>
> MCR range tables use the final MMIO offset of a register (including the
> 0x38 GSI offset when applicable). Since the i915_mcr_reg_t passed
> as a parameter during steering lookup does not include the GSI offset,
> we need to add it back in for GSI registers before searching the tables.
>
> Fixes: a7ec65fc7e83 ("drm/i915/xelpmp: Add multicast steering for media GT")
LGTM,
Reviewed-by: Radhakrishna Sripada
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> index a4a8b8bc5737..03632df27de3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> @@ -561,12 +561,15 @@ static bool reg_needs_read_steering(struct intel_gt
> *gt,
> i915_mcr_reg_t reg,
> enum intel_steering_type type)
> {
> - const u32 offset = i915_mmio_reg_offset(reg);
> + u32 offset = i915_mmio_reg_offset(reg);
> const struct intel_mmio_range *entry;
>
> if (likely(!gt->steering_table[type]))
> return false;
>
> + if (IS_GSI_REG(offset))
> + offset += gt->uncore->gsi_offset;
> +
> for (entry = gt->steering_table[type]; entry->end; entry++) {
> if (offset >= entry->start && offset <= entry->end)
> return true;
> --
> 2.39.1
Re: [Intel-gfx] [PATCH v7 2/2] drm/i915/mtl: update scaler source and destination limits for MTL
Merged the two patches. Thanks for the review and the patch.
Regards,
Radhakrishna(RK) Sripada
> -Original Message-
> From: Intel-gfx On Behalf Of
> Lisovskiy, Stanislav
> Sent: Sunday, January 8, 2023 11:32 PM
> To: Coelho, Luciano
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v7 2/2] drm/i915/mtl: update scaler source and
> destination limits for MTL
>
> On Fri, Dec 23, 2022 at 03:05:09PM +0200, Luca Coelho wrote:
> > From: Animesh Manna
> >
> > The max source and destination limits for scalers in MTL have changed.
> > Use the new values accordingly.
> >
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Animesh Manna
> > Signed-off-by: Luca Coelho
> > ---
> >
> > In v2:
> >* No changes;
> >
> > In v3:
> >* Removed stray reviewed-by tag;
> >* Added my s-o-b.
> >
> > In v4:
> >* No changes.
> >
> > In v5:
> >* Just resent with a cover letter.
> >
> > In v6:
> >* Now the correct version again (same as v4).
> >
> > In v7:
> >* Update to new MTL limits according to the bspec.
> >
> >
> > drivers/gpu/drm/i915/display/skl_scaler.c | 40 ++-
> > 1 file changed, 32 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
> b/drivers/gpu/drm/i915/display/skl_scaler.c
> > index d7390067b7d4..01e881293612 100644
> > --- a/drivers/gpu/drm/i915/display/skl_scaler.c
> > +++ b/drivers/gpu/drm/i915/display/skl_scaler.c
> > @@ -87,6 +87,10 @@ static u16 skl_scaler_calc_phase(int sub, int scale, bool
> chroma_cosited)
> > #define ICL_MAX_SRC_H 4096
> > #define ICL_MAX_DST_W 5120
> > #define ICL_MAX_DST_H 4096
> > +#define MTL_MAX_SRC_W 4096
> > +#define MTL_MAX_SRC_H 8192
> > +#define MTL_MAX_DST_W 8192
> > +#define MTL_MAX_DST_H 8192
> > #define SKL_MIN_YUV_420_SRC_W 16
> > #define SKL_MIN_YUV_420_SRC_H 16
> >
> > @@ -103,6 +107,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
> bool force_detach,
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > const struct drm_display_mode *adjusted_mode =
> > _state->hw.adjusted_mode;
> > + int min_src_w, min_src_h, min_dst_w, min_dst_h;
> > + int max_src_w, max_src_h, max_dst_w, max_dst_h;
> >
> > /*
> > * Src coordinates are already rotated by 270 degrees for
> > @@ -157,15 +163,33 @@ skl_update_scaler(struct intel_crtc_state
> *crtc_state, bool force_detach,
> > return -EINVAL;
> > }
> >
> > + min_src_w = SKL_MIN_SRC_W;
> > + min_src_h = SKL_MIN_SRC_H;
> > + min_dst_w = SKL_MIN_DST_W;
> > + min_dst_h = SKL_MIN_DST_H;
> > +
> > + if (DISPLAY_VER(dev_priv) < 11) {
> > + max_src_w = SKL_MAX_SRC_W;
> > + max_src_h = SKL_MAX_SRC_H;
> > + max_dst_w = SKL_MAX_DST_W;
> > + max_dst_h = SKL_MAX_DST_H;
> > + } else if (DISPLAY_VER(dev_priv) < 14) {
> > + max_src_w = ICL_MAX_SRC_W;
> > + max_src_h = ICL_MAX_SRC_H;
> > + max_dst_w = ICL_MAX_DST_W;
> > + max_dst_h = ICL_MAX_DST_H;
> > + } else {
> > + max_src_w = MTL_MAX_SRC_W;
> > + max_src_h = MTL_MAX_SRC_H;
> > + max_dst_w = MTL_MAX_DST_W;
> > + max_dst_h = MTL_MAX_DST_H;
> > + }
> > +
> > /* range checks */
> > - if (src_w < SKL_MIN_SRC_W || src_h < SKL_MIN_SRC_H ||
> > - dst_w < SKL_MIN_DST_W || dst_h < SKL_MIN_DST_H ||
> > - (DISPLAY_VER(dev_priv) >= 11 &&
> > -(src_w > ICL_MAX_SRC_W || src_h > ICL_MAX_SRC_H ||
> > - dst_w > ICL_MAX_DST_W || dst_h > ICL_MAX_DST_H)) ||
> > - (DISPLAY_VER(dev_priv) < 11 &&
> > -(src_w > SKL_MAX_SRC_W || src_h > SKL_MAX_SRC_H ||
> > - dst_w > SKL_MAX_DST_W || dst_h > SKL_MAX_DST_H))) {
> > + if (src_w < min_src_w || src_h < min_src_h ||
> > + dst_w < min_dst_w || dst_h < min_dst_h ||
> > + src_w > max_src_w || src_h > max_src_h ||
> > + dst_w > max_dst_w || dst_h > max_dst_h) {
>
> Yep, that looks definitely way cleaner than initial condition.
>
> Reviewed-by: Stanislav Lisovskiy
>
> > drm_dbg_kms(_priv->drm,
> > "scaler_user index %u.%u: src %ux%u dst %ux%u "
> > "size is out of scaler range\n",
> > --
> > 2.39.0
> >
Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Add initial gt workarounds
Pushed with the nit's fixed. Thanks for the patch and review.
- Radhakrishna(RK) Sripada
> -Original Message-
> From: Intel-gfx On Behalf Of Rodrigo
> Vivi
> Sent: Friday, January 6, 2023 5:04 AM
> To: Atwood, Matthew S
> Cc: intel-gfx@lists.freedesktop.org; De Marchi, Lucas
>
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/mtl: Add initial gt workarounds
>
> On Thu, Jan 05, 2023 at 03:44:08PM -0800, Matt Atwood wrote:
> > From: Matt Roper
> >
> > This patch introduces initial gt workarounds for the MTL platform.
> >
> > v2: drop redundant/stale comments specifying wa platforms affected
> > (Lucas).
> > v3: drop additional redundant stale comments (MattR)
> >
> > Bspec: 66622
> >
> > Signed-off-by: Matt Roper
> > Signed-off-by: Matt Atwood
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +-
> > .../drm/i915/gt/intel_execlists_submission.c | 6 +-
> > drivers/gpu/drm/i915/gt/intel_gt_mcr.c| 11 +-
> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 115 +-
> > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 9 +-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +-
> > drivers/gpu/drm/i915/i915_drv.h | 4 +
> > drivers/gpu/drm/i915/intel_device_info.c | 6 +
> > 9 files changed, 128 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 99c4b866addd..e3f30bdf7e61 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -1494,10 +1494,12 @@ static int __intel_engine_stop_cs(struct
> intel_engine_cs *engine,
> > intel_uncore_write_fw(uncore, mode,
> _MASKED_BIT_ENABLE(STOP_RING));
> >
> > /*
> > -* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
> > +* Wa_22011802037 : Prior to doing a reset, ensure CS is
>
> ^ you could've had also removed the extra space
>
> > * stopped, set ring stop bit and prefetch disable bit to halt CS
> > */
> > - if (IS_GRAPHICS_VER(engine->i915, 11, 12))
> > + if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
> > + (GRAPHICS_VER(engine->i915) >= 11 &&
> > + GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
>
> this is getting hard to read, but yeap, this is the only way...
>
> > intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine-
> >mmio_base),
> >
> _MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 2daffa7c7dfd..18ffe55282e5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -2989,10 +2989,12 @@ static void execlists_reset_prepare(struct
> intel_engine_cs *engine)
> > intel_engine_stop_cs(engine);
> >
> > /*
> > -* Wa_22011802037:gen11/gen12: In addition to stopping the cs, we
> need
> > +* Wa_22011802037: In addition to stopping the cs, we need
> > * to wait for any pending mi force wakeups
> > */
> > - if (IS_GRAPHICS_VER(engine->i915, 11, 12))
> > + if (IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
> > + (GRAPHICS_VER(engine->i915) >= 11 &&
> > + GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70)))
> > intel_engine_wait_for_pending_mi_fw(engine);
> >
> > engine->execlists.reset_ccid = active_ccid(engine);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > index 41a237509dcf..4127830c33ca 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > @@ -164,8 +164,15 @@ void intel_gt_mcr_init(struct intel_gt *gt)
> > if (MEDIA_VER(i915) >= 13 && gt->type == GT_MEDIA) {
> > gt->steering_table[OADDRM] =
> xelpmp_oaddrm_steering_table;
> > } else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
> > - fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
> > -intel_uncore_read(gt->uncore,
> XEHP_FUSE4));
> > + /* Wa_14016747170 */
> > + if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > + IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
> > + fuse = REG_FIELD_GET(MTL_GT_L3_EXC_MASK,
> > +intel_uncore_read(gt->uncore,
> > +
> MTL_GT_ACTIVITY_FACTOR));
> > + else
> > + fuse = REG_FIELD_GET(GT_L3_EXC_MASK,
> > +intel_uncore_read(gt->uncore,
> XEHP_FUSE4));
> >
> > /*
> > * Despite the register field being named "exclude mask" the
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index
Re: [Intel-gfx] [PATCH] drm/i915: Remove __maybe_unused from used
> -Original Message-
> From: De Marchi, Lucas
> Sent: Wednesday, December 14, 2022 11:50 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sripada, Radhakrishna ; De Marchi, Lucas
>
> Subject: [PATCH] drm/i915: Remove __maybe_unused from used
>
> The attribute __maybe_unused should remain only until the respective
> info is not in the pciidlist. The info can't be added together
> with its definition because that would cause the driver to automatically
> probe for the device, while it's still not ready for that. However once
> pciidlist contains it, the attribute can be removed.
>
> Fixes: 7835303982d1 ("drm/i915/mtl: Add MeteorLake PCI IDs")
Thank you for catching this.
Reviewed-by: Radhakrishna Sripada
-RK
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 3f803c1280c0..fe28104d2ae4 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1130,7 +1130,6 @@ static const struct intel_gt_definition
> xelpmp_extra_gt[] = {
> {}
> };
>
> -__maybe_unused
> static const struct intel_device_info mtl_info = {
> XE_HP_FEATURES,
> XE_LPDP_FEATURES,
> --
> 2.38.1
Re: [Intel-gfx] [PATCH 01/20] drm/i915/mtl: Initial DDI port setup
> -Original Message-
> From: Kahola, Mika
> Sent: Friday, October 14, 2022 5:47 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika ; Taylor, Clinton A
> ; Sripada, Radhakrishna
>
> Subject: [PATCH 01/20] drm/i915/mtl: Initial DDI port setup
>
> From: Clint Taylor
>
> Initialize c10 combo phy ports. TODO Type-C ports.
>
> Cc: Radhakrishna Sripada
>
Shouldn't this be moved after C10 phy patches. Apart from that.
Reviewed-by: Radhakrishna Sripada
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c52da2a21896..6a8937a7d2d9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7900,7 +7900,11 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> if (!HAS_DISPLAY(dev_priv))
> return;
>
> - if (IS_DG2(dev_priv)) {
> + if (IS_METEORLAKE(dev_priv)) {
> + /* TODO: initialize TC ports as well */
> + intel_ddi_init(dev_priv, PORT_A);
> + intel_ddi_init(dev_priv, PORT_B);
> + } else if (IS_DG2(dev_priv)) {
> intel_ddi_init(dev_priv, PORT_A);
> intel_ddi_init(dev_priv, PORT_B);
> intel_ddi_init(dev_priv, PORT_C);
> --
> 2.34.1
Re: [Intel-gfx] [PATCH 07/20] drm/i915/mtl: Add support for PM DEMAND
> -Original Message-
> From: Kahola, Mika
> Sent: Friday, October 14, 2022 5:47 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika ; Atwood, Matthew S
> ; Roper, Matthew D
> ; De Marchi, Lucas ;
> Souza, Jose ; Sripada, Radhakrishna
>
> Subject: [PATCH 07/20] drm/i915/mtl: Add support for PM DEMAND
>
> Display14 introduces a new way to instruct the PUnit with
> power and bandwidth requirements of DE. Add the functionality
> to program the registers and handle waits using interrupts.
> The current wait time for timeouts is programmed for 10 msecs to
> factor in the worst case scenarios. Changes made to use REG_BIT
> for a register that we touched(GEN8_DE_MISC_IER _MMIO).
>
> Bspec: 66451, 64636, 64602, 64603
>
> Cc: Matt Atwood
> Cc: Matt Roper
> Cc: Lucas De Marchi
>
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 4 +-
> drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> drivers/gpu/drm/i915/display/intel_display.c | 14 +
> .../drm/i915/display/intel_display_power.c| 8 +
> drivers/gpu/drm/i915/i915_drv.h | 12 +
> drivers/gpu/drm/i915/i915_irq.c | 22 +-
> drivers/gpu/drm/i915/i915_reg.h | 33 +-
> drivers/gpu/drm/i915/intel_pm.c | 286 ++
> drivers/gpu/drm/i915/intel_pm.h | 35 +++
> 9 files changed, 411 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 4ace026b29bd..6c467b6f2234 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -716,8 +716,8 @@ static unsigned int intel_bw_num_active_planes(struct
> drm_i915_private *dev_priv
> return num_active_planes;
> }
>
> -static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> -const struct intel_bw_state *bw_state)
> +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> + const struct intel_bw_state *bw_state)
> {
> unsigned int data_rate = 0;
> enum pipe pipe;
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index cb7ee3a24a58..b3eb82a71e6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
> int intel_bw_atomic_check(struct intel_atomic_state *state);
> void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> const struct intel_crtc_state *crtc_state);
> +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> + const struct intel_bw_state *bw_state);
> int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> u32 points_mask);
> int intel_bw_calc_min_cdclk(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 0a8749753e6e..5ce33319b70d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1079,6 +1079,9 @@ intel_get_crtc_new_encoder(const struct
> intel_atomic_state *state,
> num_encoders++;
> }
>
> + if (!encoder)
> + return NULL;
> +
> drm_WARN(encoder->base.dev, num_encoders != 1,
>"%d encoders for pipe %c\n",
>num_encoders, pipe_name(master_crtc->pipe));
> @@ -6898,6 +6901,10 @@ static int intel_atomic_check(struct drm_device
> *dev,
> ret = intel_modeset_calc_cdclk(state);
> if (ret)
> return ret;
> +
> + ret = intel_pmdemand_atomic_check(state);
> + if (ret)
> + goto fail;
> }
>
> ret = intel_atomic_check_crtcs(state);
> @@ -7521,6 +7528,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> }
>
> intel_sagv_pre_plane_update(state);
> + intel_pmdemand_pre_plane_update(state);
>
> /* Complete the events for pipes that have now been disabled */
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> @@ -7622,6 +7630,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> intel_verify_planes(state);
>
> intel_sagv_post_plane_update(state);
> + intel_pmdemand_post_plane_update(stat
Re: [Intel-gfx] [PATCH] drm/i915: Use graphics ver, rel info for media on old platforms
Thank you for the feedback. Incorporated the review and posted new patches here
[1].
Thanks,
Radhakrishna(RK) Sripada
[1] https://patchwork.freedesktop.org/series/109588/
> -Original Message-
> From: Ville Syrjälä
> Sent: Tuesday, October 11, 2022 3:33 AM
> To: Jani Nikula
> Cc: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org; De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Use graphics ver, rel info for
> media on
> old platforms
>
> On Tue, Oct 11, 2022 at 01:10:26PM +0300, Jani Nikula wrote:
> > On Tue, 11 Oct 2022, "Sripada, Radhakrishna"
> wrote:
> > > Hi Jani,
> > >
> > >> -Original Message-
> > >> From: Jani Nikula
> > >> Sent: Tuesday, October 11, 2022 12:28 AM
> > >> To: Sripada, Radhakrishna ; intel-
> > >> g...@lists.freedesktop.org
> > >> Cc: dri-de...@lists.freedesktop.org; Sripada, Radhakrishna
> > >> ; De Marchi, Lucas
> > >> ; Roper, Matthew D
> > >>
> > >> Subject: Re: [PATCH] drm/i915: Use graphics ver, rel info for media on
> > >> old
> > >> platforms
> > >>
> > >> On Mon, 10 Oct 2022, Radhakrishna Sripada
>
> > >> wrote:
> > >> > Platforms prior to MTL do not have a separate media and graphics
> version.
> > >> > On platforms where GMD id is not supported, reuse the graphics ip
> version,
> > >> > release info for media.
> > >> >
> > >> > The rest of the IP graphics, display versions would be copied during
> > >> > driver
> > >> > creation.
> > >> >
> > >> > While at it warn if GMD is not used for platforms greater than gen12.
> > >> >
> > >> > Fixes: c2c7075225ef ("drm/i915: Read graphics/media/display arch
> version
> > >> from hw")
> > >> > Cc: Jani Nikula
> > >> > Cc: Lucas De Marchi
> > >> > Cc: Matt Roper
> > >> > Signed-off-by: Radhakrishna Sripada
> > >> > ---
> > >> > drivers/gpu/drm/i915/intel_device_info.c | 12 +++-
> > >> > 1 file changed, 11 insertions(+), 1 deletion(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > >> b/drivers/gpu/drm/i915/intel_device_info.c
> > >> > index 090097bb3c0a..ba178b61bceb 100644
> > >> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > >> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > >> > @@ -329,8 +329,18 @@ static void intel_ipver_early_init(struct
> > >> drm_i915_private *i915)
> > >> > {
> > >> >struct intel_runtime_info *runtime = RUNTIME_INFO(i915);
> > >> >
> > >> > - if (!HAS_GMD_ID(i915))
> > >> > + if (!HAS_GMD_ID(i915)) {
> > >> > + drm_WARN_ON(>drm, RUNTIME_INFO(i915)-
> > >> >graphics.ip.ver > 12);
> > >> > + /*
> > >> > + * On older platforms, graphics and media share the
> > >> > same ip
> > >> > + * version and release.
> > >> > + */
> > >> > + RUNTIME_INFO(i915)->media.ip.ver =
> > >> > + RUNTIME_INFO(i915)->graphics.ip.ver;
> > >> > + RUNTIME_INFO(i915)->media.ip.rel =
> > >> > + RUNTIME_INFO(i915)->graphics.ip.rel;
> > >>
> > >> You could assign the whole struct ip_version (*) at once, or is there a
> > >> reason you're intentionally not assigning step?
> > > Step info would anyways be determined later in the function
> > > intel_step_init.
> > > We already have macros in place to handle common gt and media steps
> there.
> > >
> > > Do you suggest we memcpy(_INFO(i915)->media.ip,
> _INFO->graphics.ip, sizeof(struct ip_version)) here?
> >
> > Simple assign should do it for such a small struct.
>
> IMO for any struct. Only use memcpy() when copying arrays and such.
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH] drm/i915: Use graphics ver, rel info for media on old platforms
Hi Jani,
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, October 11, 2022 12:28 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Sripada, Radhakrishna
> ; De Marchi, Lucas
> ; Roper, Matthew D
>
> Subject: Re: [PATCH] drm/i915: Use graphics ver, rel info for media on old
> platforms
>
> On Mon, 10 Oct 2022, Radhakrishna Sripada
> wrote:
> > Platforms prior to MTL do not have a separate media and graphics version.
> > On platforms where GMD id is not supported, reuse the graphics ip version,
> > release info for media.
> >
> > The rest of the IP graphics, display versions would be copied during driver
> > creation.
> >
> > While at it warn if GMD is not used for platforms greater than gen12.
> >
> > Fixes: c2c7075225ef ("drm/i915: Read graphics/media/display arch version
> from hw")
> > Cc: Jani Nikula
> > Cc: Lucas De Marchi
> > Cc: Matt Roper
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/intel_device_info.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> > index 090097bb3c0a..ba178b61bceb 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -329,8 +329,18 @@ static void intel_ipver_early_init(struct
> drm_i915_private *i915)
> > {
> > struct intel_runtime_info *runtime = RUNTIME_INFO(i915);
> >
> > - if (!HAS_GMD_ID(i915))
> > + if (!HAS_GMD_ID(i915)) {
> > + drm_WARN_ON(>drm, RUNTIME_INFO(i915)-
> >graphics.ip.ver > 12);
> > + /*
> > +* On older platforms, graphics and media share the same ip
> > +* version and release.
> > +*/
> > + RUNTIME_INFO(i915)->media.ip.ver =
> > + RUNTIME_INFO(i915)->graphics.ip.ver;
> > + RUNTIME_INFO(i915)->media.ip.rel =
> > + RUNTIME_INFO(i915)->graphics.ip.rel;
>
> You could assign the whole struct ip_version (*) at once, or is there a
> reason you're intentionally not assigning step?
Step info would anyways be determined later in the function intel_step_init.
We already have macros in place to handle common gt and media steps there.
Do you suggest we memcpy(_INFO(i915)->media.ip,
_INFO->graphics.ip, sizeof(struct ip_version)) here?
>
> BR,
> Jani.
>
> (*) Why does that name not have intel_ prefix?
Good question. Since introduced in " a5b7ef27da60 drm/i915: Add struct to hold
IP version"
we have been using as is. The author might have felt that the structure is not
big enough/used in as many places
to have an intel_ prefix. Do you see a symbol collision here that we need to
add intel_ prefix? If so should we do it
in a separate patch?
Thanks,
Radhakrishna(RK) Sripada
>
> > return;
> > + }
> >
> > ip_ver_read(i915, i915_mmio_reg_offset(GMD_ID_GRAPHICS),
> > >graphics.ip);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Extend PSR support
Merged the patch. Thank you for the patch and review.
- Radhakrishna(RK) Sripada
> -Original Message-
> From: Intel-gfx On Behalf Of
> Lisovskiy, Stanislav
> Sent: Friday, September 23, 2022 1:09 AM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Extend PSR support
>
> On Wed, Sep 07, 2022 at 11:15:43AM +0300, Mika Kahola wrote:
> > From: José Roberto de Souza
> >
> > Meteorlake and display 14 platform don't have any PSR differences
> > when comparing to Alderlake-P display, so it was only necessary to
> > extend some checks to properly program hardware.
> >
> > BSpec: 55229, 49196
>
> Reviewed-by: Stanislav Lisovskiy
>
> >
> > Cc: Mika Kahola
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 31 +++-
> > drivers/gpu/drm/i915/i915_reg.h | 5
> > 2 files changed, 25 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 079b7d3d0c53..4170017969c9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -515,7 +515,7 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
> >
> > val |= psr_compute_idle_frames(intel_dp) <<
> EDP_PSR2_IDLE_FRAME_SHIFT;
> >
> > - if (!IS_ALDERLAKE_P(dev_priv))
> > + if (DISPLAY_VER(dev_priv) <= 13 && !IS_ALDERLAKE_P(dev_priv))
> > val |= EDP_SU_TRACK_ENABLE;
> >
> > if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
> > @@ -598,7 +598,7 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
> > static bool
> > transcoder_has_psr2(struct drm_i915_private *dev_priv, enum transcoder
> trans)
> > {
> > - if (IS_ALDERLAKE_P(dev_priv))
> > + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14)
> > return trans == TRANSCODER_A || trans == TRANSCODER_B;
> > else if (DISPLAY_VER(dev_priv) >= 12)
> > return trans == TRANSCODER_A;
> > @@ -678,7 +678,7 @@ dc3co_is_pipe_port_compatible(struct intel_dp
> *intel_dp,
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > enum port port = dig_port->base.port;
> >
> > - if (IS_ALDERLAKE_P(dev_priv))
> > + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14)
> > return pipe <= PIPE_B && port <= PORT_B;
> > else
> > return pipe == PIPE_A && port == PORT_A;
> > @@ -777,11 +777,11 @@ static bool psr2_granularity_check(struct intel_dp
> *intel_dp,
> > return intel_dp->psr.su_y_granularity == 4;
> >
> > /*
> > -* adl_p has 1 line granularity. For other platforms with SW tracking we
> > -* can adjust the y coordinates to match sink requirement if multiple of
> > -* 4.
> > +* adl_p and display 14+ platforms has 1 line granularity.
> > +* For other platforms with SW tracking we can adjust the y coordinates
> > +* to match sink requirement if multiple of 4.
> > */
> > - if (IS_ALDERLAKE_P(dev_priv))
> > + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14)
> > y_granularity = intel_dp->psr.su_y_granularity;
> > else if (intel_dp->psr.su_y_granularity <= 2)
> > y_granularity = 4;
> > @@ -864,7 +864,8 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> > * resolution requires DSC to be enabled, priority is given to DSC
> > * over PSR2.
> > */
> > - if (crtc_state->dsc.compression_enable) {
> > + if (crtc_state->dsc.compression_enable &&
> > + (DISPLAY_VER(dev_priv) <= 13 && !IS_ALDERLAKE_P(dev_priv))) {
> > drm_dbg_kms(_priv->drm,
> > "PSR2 cannot be enabled since DSC is enabled\n");
> > return false;
> > @@ -1457,7 +1458,7 @@ static u32 man_trk_ctl_enable_bit_get(struct
> drm_i915_private *dev_priv)
> >
> > static u32 man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private
> *dev_priv)
> > {
> > - return IS_ALDERLAKE_P(dev_priv) ?
> > + return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ?
> >ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME :
> >PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > }
> > @@ -1610,7 +1611,7 @@ static void psr2_man_trk_ctl_calc(struct
> intel_crtc_state *crtc_state,
> > if (clip->y1 == -1)
> > goto exit;
> >
> > - if (IS_ALDERLAKE_P(dev_priv)) {
> > + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14) {
> > val |=
> ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1);
> > val |=
> ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 - 1);
> > } else {
> > @@ -1647,7 +1648,15 @@ static void
> intel_psr2_sel_fetch_pipe_alignment(const struct intel_crtc_state *c
> > struct drm_rect *pipe_clip)
> > {
> > struct drm_i915_private
Re: [Intel-gfx] [PATCH v4.1] drm/i915/mtl: Define engine context layouts
> -Original Message- > From: De Marchi, Lucas > Sent: Thursday, September 29, 2022 5:11 PM > To: Sripada, Radhakrishna > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [PATCH v4.1] drm/i915/mtl: Define engine context layouts > > On Wed, Sep 28, 2022 at 08:55:11AM -0700, Radhakrishna Sripada wrote: > >From: Matt Roper > > > >The part of the media and blitter engine contexts that we care about for > >setting up an initial state on MTL are nearly similar to DG2 (and PVC). > >The difference being PRT_BB_STATE being replaced with NOP. > > > >For render/compute engines, the part of the context images are nearly > >the same, although the layout had a very slight change --- one POSH > >register was removed and the placement of some LRI/noops adjusted > >slightly to compensate. > > > >v2: > > - Dg2, mtl xcs offsets slightly vary. Use a separate offsets array(Bala) > > - Add missing nop in xcs offsets(Bala) > >v3: > > - Fix the spacing for nop in xcs offset(MattR) > >v4: > > - Fix rcs register offset(MattR) > >v4.1: > > - Fix commit message(Lucas) > > > >Bspec: 46261, 46260, 45585 > >Cc: Balasubramani Vivekanandan > >Cc: Licas De Marchi > >Signed-off-by: Matt Roper > >Signed-off-by: Radhakrishna Sripada > > > Reviewed-by: Lucas De Marchi Pushed the patch, Thanks for the review. -Radhakrishna Sripada > > Lucas De Marchi
