Re: [Intel-gfx] [PATCH 1/3] drm/i915/dg2: Enable 5th display
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, February 15, 2022 11:22 AM
> To: intel-gfx ; dri-devel de...@lists.freedesktop.org>
> Cc: Ville Syrjälä ; Shankar, Uma
> ; Roper, Matthew D ;
> Dhanavanthri, Swathi ; De Marchi, Lucas
> ; Souza, Jose ; C, Ramalingam
>
> Subject: [PATCH 1/3] drm/i915/dg2: Enable 5th display
>
> From: Matt Roper
>
> DG2 supports a 5th display output which the hardware refers to as "TC1,"
> even though it isn't a Type-C output. This behaves similarly to the TC1 on
> past
> platforms with just a couple minor differences:
>
> * DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on
>ICP/TGP/ADP.
> * DG2 doesn't need the hpd inversion setting that we had to use on DG1
>
> Cc: Swathi Dhanavanthri
> Cc: Lucas De Marchi
> Cc: José Roberto de Souza
> Signed-off-by: Matt Roper
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_gmbus.c | 16 ++--
> drivers/gpu/drm/i915/i915_irq.c| 5 -
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> 3 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index 6ce8c10fe975..2fad03250661 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -98,11 +98,21 @@ static const struct gmbus_pin gmbus_pins_dg1[] = {
> [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
> };
>
> +static const struct gmbus_pin gmbus_pins_dg2[] = {
> + [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
> + [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
> + [GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
> + [GMBUS_PIN_4_CNP] = { "dpd", GPIOE },
> + [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ }, };
> +
> /* pin is expected to be valid */
> static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private
> *dev_priv,
>unsigned int pin)
> {
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG2)
> + return &gmbus_pins_dg2[pin];
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> return &gmbus_pins_dg1[pin];
> else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> return &gmbus_pins_icp[pin];
> @@ -123,7 +133,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private
> *dev_priv, {
> unsigned int size;
>
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG2)
> + size = ARRAY_SIZE(gmbus_pins_dg2);
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> size = ARRAY_SIZE(gmbus_pins_dg1);
> else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
> size = ARRAY_SIZE(gmbus_pins_icp);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c index
> fdd568ba4a16..4d81063b128c 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -179,6 +179,7 @@ static const u32 hpd_sde_dg1[HPD_NUM_PINS] = {
> [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_B),
> [HPD_PORT_C] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_C),
> [HPD_PORT_D] = SDE_DDI_HOTPLUG_ICP(HPD_PORT_D),
> + [HPD_PORT_TC1] = SDE_TC_HOTPLUG_DG2(HPD_PORT_TC1),
Not sure if this applies to DG1, the 5th TC1 port is only for DG2. Should we
not have a separate
DG2 struct. Can you please clarify to help understand.
Regards,
Uma Shankar
> };
>
> static void intel_hpd_init_pins(struct drm_i915_private *dev_priv) @@ -4424,7
> +4425,9 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> if (I915_HAS_HOTPLUG(dev_priv))
> dev_priv->hotplug_funcs = &i915_hpd_funcs;
> } else {
> - if (HAS_PCH_DG1(dev_priv))
> + if (HAS_PCH_DG2(dev_priv))
> + dev_priv->hotplug_funcs = &icp_hpd_funcs;
> + else if (HAS_PCH_DG1(dev_priv))
> dev_priv->hotplug_funcs = &dg1_hpd_funcs;
> else if (DISPLAY_VER(dev_priv) >= 11)
> dev_priv->hotplug_funcs = &gen11_hpd_funcs; diff --git
> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index
> 4ea1713e6b60..4d12abb2d7ff 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6182,6 +6182,7 @@
> /* south display engine interrupt: ICP/TGP */
> #define SDE_GMBUS_ICP(1 << 23)
> #define SDE_TC_HOTPLUG_ICP(hpd_pin) REG_BIT(24 +
> _HPD_PIN_TC(hpd_pin))
> +#define SDE_TC_HOTPLUG_DG2(hpd_pin) REG_BIT(25 +
> _HPD_PIN_TC(hpd_pin)) /* sigh */
> #define SDE_DDI_HOTPLUG_ICP(hpd_pin) REG_BIT(16 +
> _HPD_PIN_DDI(hpd_pin))
> #define SDE_DDI_HOTPLUG_MASK_ICP (SDE_DDI_HOTPLUG_ICP(HPD_PORT_D) | \
>SDE_DDI_HOTPLUG_ICP(HPD_PORT_C) | \
> --
> 2.20.1
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dg2: Drop 38.4 MHz MPLLB tables
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, February 15, 2022 11:22 AM
> To: intel-gfx ; dri-devel de...@lists.freedesktop.org>
> Cc: Ville Syrjälä ; Shankar, Uma
> ; Roper, Matthew D ;
> Srivatsa, Anusha ; Souza, Jose
> ; C, Ramalingam
> Subject: [PATCH 2/3] drm/i915/dg2: Drop 38.4 MHz MPLLB tables
>
> From: Matt Roper
>
> Our early understanding of DG2 was incorrect; since the 5th display isn't
> actually a
> Type-C output, 38.4 MHz input clocks are never used on this platform and we
> can
> drop the corresponding MPLLB tables.
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Anusha Srivatsa
> Cc: José Roberto de Souza
> Signed-off-by: Matt Roper
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_snps_phy.c | 208 +-
> 1 file changed, 1 insertion(+), 207 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index 8573a458811a..c60575cb5368 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -250,197 +250,6 @@ static const struct intel_mpllb_state * const
> dg2_dp_100_tables[] = {
> NULL,
> };
>
> -/*
> - * Basic DP link rates with 38.4 MHz reference clock.
> - */
> -
> -static const struct intel_mpllb_state dg2_dp_rbr_38_4 = {
> - .clock = 162000,
> - .ref_control =
> - REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
> - .mpllb_cp =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
> - .mpllb_div =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 2) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 2),
> - .mpllb_div2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 304),
> - .mpllb_fracn1 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
> - .mpllb_fracn2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 49152),
> -};
> -
> -static const struct intel_mpllb_state dg2_dp_hbr1_38_4 = {
> - .clock = 27,
> - .ref_control =
> - REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
> - .mpllb_cp =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
> - .mpllb_div =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3),
> - .mpllb_div2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 248),
> - .mpllb_fracn1 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
> - .mpllb_fracn2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 40960),
> -};
> -
> -static const struct intel_mpllb_state dg2_dp_hbr2_38_4 = {
> - .clock = 54,
> - .ref_control =
> - REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
> - .mpllb_cp =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
> - .mpllb_div =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3),
> - .mpllb_div2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 248),
> - .mpllb_fracn1 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
> - .mpllb_fracn2 =
> - REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 40960),
> -};
> -
> -static const struct intel_mpllb_sta
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
> -Original Message-
> From: C, Ramalingam
> Sent: Tuesday, February 15, 2022 11:22 AM
> To: intel-gfx ; dri-devel de...@lists.freedesktop.org>
> Cc: Ville Syrjälä ; Shankar, Uma
> ; Hogander, Jouni ; C,
> Ramalingam
> Subject: [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
>
> From: Jouni Högander
>
> Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E port.
> Correct
> offset is 0x64C14.
>
> Fix this by handling PHY_E port seprately.
>
> Signed-off-by: Matt Roper
> Signed-off-by: Jouni Högander
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 6 --
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index c60575cb5368..f08061c748b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -32,7 +32,7 @@ void intel_snps_phy_wait_for_calibration(struct
> drm_i915_private *i915)
> if (!intel_phy_is_snps(i915, phy))
> continue;
>
> - if (intel_de_wait_for_clear(i915, ICL_PHY_MISC(phy),
> + if (intel_de_wait_for_clear(i915, DG2_PHY_MISC(phy),
> DG2_PHY_DP_TX_ACK_MASK, 25))
> drm_err(&i915->drm, "SNPS PHY %c failed to calibrate
> after
> 25ms.\n",
> phy);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4d12abb2d7ff..354c25f483cb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9559,8 +9559,10 @@ enum skl_power_gate {
>
> #define _ICL_PHY_MISC_A 0x64C00
> #define _ICL_PHY_MISC_B 0x64C04
> -#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A, \
> - _ICL_PHY_MISC_B)
> +#define _DG2_PHY_MISC_TC10x64C14 /* TC1="PHY E" but offset as if "PHY F"
> */
> +#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A,
> _ICL_PHY_MISC_B)
Nit: Align it as was defined earlier to honor line limit.
Looks Good to me.
Reviewed-by: Uma Shankar
> +#define DG2_PHY_MISC(port) ((port) == PHY_E ? _MMIO(_DG2_PHY_MISC_TC1) :
> \
> + ICL_PHY_MISC(port))
> #define ICL_PHY_MISC_MUX_DDID (1 << 28)
> #define ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
> #define DG2_PHY_DP_TX_ACK_MASK REG_GENMASK(23, 20)
> --
> 2.20.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation
== Series Details ==
Series: drm/mm: Add an iterator to optimally walk over holes suitable for an
allocation
URL : https://patchwork.freedesktop.org/series/100136/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11230_full -> Patchwork_22273_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22273_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22273_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
--
Missing(1): shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22273_full:
### IGT changes ###
Possible regressions
* igt@gem_eio@kms:
- shard-glk: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk3/igt@gem_...@kms.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-glk8/igt@gem_...@kms.html
Warnings
* igt@kms_ccs@pipe-d-random-ccs-data-yf_tiled_ccs:
- shard-tglb: [SKIP][3] ([fdo#111615] / [i915#3689]) ->
[INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-tglb8/igt@kms_ccs@pipe-d-random-ccs-data-yf_tiled_ccs.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-tglb8/igt@kms_ccs@pipe-d-random-ccs-data-yf_tiled_ccs.html
Known issues
Here are the changes found in Patchwork_22273_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- {shard-rkl}:([PASS][5], [PASS][6], [PASS][7], [FAIL][8],
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14],
[PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20]) ->
([PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26],
[PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32],
[PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-6/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-6/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-6/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-5/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-5/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-5/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-5/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-4/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-4/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-2/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-2/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-2/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-1/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-1/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22273/shard-rkl-1/boot.html
[36]:
https://intel-gfx-ci.01.or
Re: [Intel-gfx] [PATCH] drm/i915/gvt: #include drm_edid.h for drm_edid_block_valid()
On 2/15/22 12:20 PM, Nikula, Jani wrote:
> As the excessive #includes from i915_drv.h were axed, kvmgt.c build
> started failing. Add the necessary #include where needed.
>
> Reported-by: Stephen Rothwell
> Fixes: 14da21cc4671 ("drm/i915: axe lots of unnecessary includes from
> i915_drv.h")
> Cc: Tvrtko Ursulin
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> Cc: intel-gvt-...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
>
> ---
>
> Going to merge this via drm-intel-next along with the regressing commit.
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 20b82fb036f8..e8d6c76e9234 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -46,6 +46,8 @@
>
> #include
>
> +#include
> +
> #include "i915_drv.h"
> #include "gvt.h"
>
>
Hi:
Thanks for the notification!
Reviewed-by: Zhi Wang
Re: [Intel-gfx] [PATCH 01/12] drm/i915: Fix cursor coordinates on bigjoiner slave
On Tue, Feb 15, 2022 at 07:25:36PM -0800, Navare, Manasi wrote: > On Tue, Feb 15, 2022 at 08:31:57PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Adjust the cursor dst coordinates appripriately when it's on > > the bigjoiner slave pipe. intel_atomic_plane_check_clipping() > > already did this but with the cursor we discard those results > > (apart from uapi.visible and error checks) since the hardware > > will be doing the clipping for us. > > > > v2: Rebase due to bigjoiner bitmask usage > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/display/intel_cursor.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c > > b/drivers/gpu/drm/i915/display/intel_cursor.c > > index 2ade8fdd9bdd..3e80763aa828 100644 > > --- a/drivers/gpu/drm/i915/display/intel_cursor.c > > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c > > @@ -152,6 +152,9 @@ static int intel_check_cursor(struct intel_crtc_state > > *crtc_state, > > /* Use the unclipped src/dst rectangles, which we program to hw */ > > plane_state->uapi.src = src; > > plane_state->uapi.dst = dst; > > + if (intel_crtc_is_bigjoiner_slave(crtc_state)) > > + drm_rect_translate(&plane_state->uapi.dst, > > + -crtc_state->pipe_src_w, 0); > > So this is basically to offset the cursor position from say 3860 to 0, 3861 > to 1 7680 to 3860 for the right half > of the screen right? > And without this, it will just keep it at first rectangle? Yes. The original rectangle came from userspace and is thus relative to the whole area covered by all the joined pipes. But the plane coordinates we hand to the hardware must be relative to their respective pipe. It's a bit ugly as is but works for now. The last patch make this much nicer by removing all the assumptions here about the relative positions of the pipes. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Define MCH registers relative to MCHBAR_MIRROR_BASE
On Mon, Feb 14, 2022 at 10:13:41PM -0800, Matt Roper wrote: > A few of our MCH registers are defined with absolute register offsets. > For consistency, let's switch their definitions to be relative offsets > from MCHBAR_MIRROR_BASE. > > Cc: Ville Syrjälä > Suggested-by: Ville Syrjälä > Signed-off-by: Matt Roper Looks correct to my eyes. Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_reg.h | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 4ea1713e6b60..72cb6e13b4e2 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1922,16 +1922,16 @@ > #define HPLLVCO _MMIO(MCHBAR_MIRROR_BASE + 0xc38) > #define HPLLVCO_MOBILE _MMIO(MCHBAR_MIRROR_BASE + 0xc0f) > > -#define TSC1 _MMIO(0x11001) > +#define TSC1 _MMIO(MCHBAR_MIRROR_BASE + 0x1001) > #define TSE(1 << 0) > -#define TR1 _MMIO(0x11006) > -#define TSFS _MMIO(0x11020) > +#define TR1 _MMIO(MCHBAR_MIRROR_BASE + 0x1006) > +#define TSFS _MMIO(MCHBAR_MIRROR_BASE + 0x1020) > #define TSFS_SLOPE_MASK0xff00 > #define TSFS_SLOPE_SHIFT 8 > #define TSFS_INTR_MASK 0x00ff > > -#define CSIPLL0 _MMIO(0x12c10) > -#define DDRMPLL1 _MMIO(0X12c20) > +#define CSIPLL0 _MMIO(MCHBAR_MIRROR_BASE + 0x2c10) > +#define DDRMPLL1 _MMIO(MCHBAR_MIRROR_BASE + 0x2c20) > #define PEG_BAND_GAP_DATA_MMIO(0x14d68) > > #define GEN6_GT_PERF_STATUS _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5948) > @@ -4320,7 +4320,7 @@ >((fbc) << WM1_LP_FBC_SHIFT) | ((pri) << WM1_LP_SR_SHIFT) | (cur)) > > /* Memory latency timer register */ > -#define MLTR_ILK _MMIO(0x11222) > +#define MLTR_ILK _MMIO(MCHBAR_MIRROR_BASE + 0x1222) > #define MLTR_WM1_SHIFT 0 > #define MLTR_WM2_SHIFT 8 > /* the unit of memory self-refresh latency time is 0.5us */ > -- > 2.34.1 -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Move MCHBAR registers to their own header
On Mon, Feb 14, 2022 at 10:13:42PM -0800, Matt Roper wrote: > Registers that exist within the MCH BAR and are mirrored into the GPU's > MMIO space are a good candidate to separate out into their own header. > > For reference, the mirror of the MCH BAR starts at the following > locations in the graphics MMIO space (the end of the MCHBAR range > differs slightly on each platform): > > * Pre-gen6: 0x1 > * Gen6-Gen11 + RKL: 0x14 > > v2: > - Create separate patch to swtich a few register definitions to be >relative to the MCHBAR mirror base. > - Drop upper bound of MCHBAR mirror from commit message; there are too >many different combinations between various platforms to list out, >and the documentation is spotty for the older pre-gen6 platforms >anyway. > > Bspec: 134, 51771 > Cc: Ville Syrjälä > Suggested-by: Ville Syrjälä > Signed-off-by: Matt Roper Reviewed-by: Ville Syrjälä -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote:
> From: Jouni Högander
>
> Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E
> port. Correct offset is 0x64C14.
Why is it PHY_E and not PHY_F?
>
> Fix this by handling PHY_E port seprately.
>
> Signed-off-by: Matt Roper
> Signed-off-by: Jouni Högander
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 6 --
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index c60575cb5368..f08061c748b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -32,7 +32,7 @@ void intel_snps_phy_wait_for_calibration(struct
> drm_i915_private *i915)
> if (!intel_phy_is_snps(i915, phy))
> continue;
>
> - if (intel_de_wait_for_clear(i915, ICL_PHY_MISC(phy),
> + if (intel_de_wait_for_clear(i915, DG2_PHY_MISC(phy),
> DG2_PHY_DP_TX_ACK_MASK, 25))
> drm_err(&i915->drm, "SNPS PHY %c failed to calibrate
> after 25ms.\n",
> phy);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4d12abb2d7ff..354c25f483cb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9559,8 +9559,10 @@ enum skl_power_gate {
>
> #define _ICL_PHY_MISC_A 0x64C00
> #define _ICL_PHY_MISC_B 0x64C04
> -#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A, \
> - _ICL_PHY_MISC_B)
> +#define _DG2_PHY_MISC_TC10x64C14 /* TC1="PHY E" but offset as if "PHY F"
> */
> +#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A,
> _ICL_PHY_MISC_B)
> +#define DG2_PHY_MISC(port) ((port) == PHY_E ? _MMIO(_DG2_PHY_MISC_TC1) : \
> + ICL_PHY_MISC(port))
> #define ICL_PHY_MISC_MUX_DDID (1 << 28)
> #define ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
> #define DG2_PHY_DP_TX_ACK_MASK REG_GENMASK(23, 20)
> --
> 2.20.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v1 1/1] drm/i915/selftests: Replace too verbose for-loop with simpler while
On Tue, 15 Feb 2022, Andy Shevchenko wrote: > On Tue, Feb 15, 2022 at 07:14:49PM +0200, Jani Nikula wrote: >> On Tue, 15 Feb 2022, Andy Shevchenko >> wrote: >> > It's hard to parse for-loop which has some magic calculations inside. >> > Much cleaner to use while-loop directly. >> >> I assume you're trying to prove a point following our recent >> for-vs-while loop discussion. I really can't think of any other reason >> you'd end up looking at this file or this loop. >> >> With the change, the loop indeed becomes simpler, but it also runs one >> iteration further than the original. Whoops. > > Yeah, sorry for that, the initial condition should be d = depth - 1, > of course. Well, no, the condition should be while (--i) instead to also match the values the original loop takes. ;D Cheers, Jani. > >> It's a selftest. The loop's been there for five years. What are we >> trying to achieve here? So we disagree on loops, fine. Perhaps this is >> not the best use of either of our time? Please just let the for loops in >> i915 be. > > Yes, I'm pretty much was sure that no-one will go and apply this anyway > (so I haven't paid too much attention), but to prove my point in the > certain discussion. > > And yes, the point is for the new code, I'm not going to change existing > suboptimal and too hard to read for-loops, it will consume my time later > when I will try to understand the code. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/gt: fix unsigned integer to signed assignment
On Wed, 16 Feb 2022, Jiapeng Chong wrote:
> Eliminate the follow smatch warning:
>
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4640
> guc_create_virtual() warn: assigning (-2) to unsigned variable
> 've->base.instance'.
>
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4641
> guc_create_virtual() warn: assigning (-2) to unsigned variable
> 've->base.uabi_instance'.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
The report seems to be valid, but I don't think this is the fix.
Where do we even check for invalid instance/uabi_instance in code?
BR,
Jani.
> ---
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 36365bdbe1ee..dc7cc06c68e7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -328,10 +328,10 @@ struct intel_engine_cs {
> intel_engine_mask_t logical_mask;
>
> u8 class;
> - u8 instance;
> + s8 instance;
>
> u16 uabi_class;
> - u16 uabi_instance;
> + s16 uabi_instance;
>
> u32 uabi_capabilities;
> u32 context_size;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v1 1/1] drm/i915/selftests: Replace too verbose for-loop with simpler while
On Wed, Feb 16, 2022 at 9:55 AM Jani Nikula wrote:
> On Tue, 15 Feb 2022, Andy Shevchenko
> wrote:
> > On Tue, Feb 15, 2022 at 07:14:49PM +0200, Jani Nikula wrote:
> >> On Tue, 15 Feb 2022, Andy Shevchenko
> >> wrote:
> >> > It's hard to parse for-loop which has some magic calculations inside.
> >> > Much cleaner to use while-loop directly.
> >>
> >> I assume you're trying to prove a point following our recent
> >> for-vs-while loop discussion. I really can't think of any other reason
> >> you'd end up looking at this file or this loop.
> >>
> >> With the change, the loop indeed becomes simpler, but it also runs one
> >> iteration further than the original. Whoops.
> >
> > Yeah, sorry for that, the initial condition should be d = depth - 1,
> > of course.
>
> Well, no, the condition should be while (--i) instead to also match the
> values the original loop takes. ;D
"There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors."
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[Intel-gfx] [RFC v3 4/5] drm/hdmi21: Add support for DFM calculation with DSC
Add helper functions for calculating FRL capacity and DFM
requirements with given compressed bpp.
v2: Fixed:
-Build warnings/errors: Removed unused variables.
-Checkpatch warnings.
Signed-off-by: Ankit Nautiyal
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/drm_frl_dfm_helper.c | 303 +++
include/drm/drm_frl_dfm_helper.h | 3 +
2 files changed, 306 insertions(+)
diff --git a/drivers/gpu/drm/drm_frl_dfm_helper.c
b/drivers/gpu/drm/drm_frl_dfm_helper.c
index b8f4f8ee50d3..95de7a6978a2 100644
--- a/drivers/gpu/drm/drm_frl_dfm_helper.c
+++ b/drivers/gpu/drm/drm_frl_dfm_helper.c
@@ -555,3 +555,306 @@ drm_frl_dfm_nondsc_requirement_met(struct
drm_hdmi_frl_dfm *frl_dfm)
return false;
}
EXPORT_SYMBOL(drm_frl_dfm_nondsc_requirement_met);
+
+/* DSC DFM functions */
+/* Get FRL Available characters */
+static u32
+drm_get_frl_available_chars(u32 overhead_max, u32 cfrl_line)
+{
+ u32 frl_char_avlb = ((EFFICIENCY_MULTIPLIER - overhead_max) *
cfrl_line);
+
+ return frl_char_avlb / EFFICIENCY_MULTIPLIER;
+}
+
+/* Get required no. of tribytes during HCActive */
+static u32
+drm_get_frl_hcactive_tb_target(u32 dsc_bpp_x16, u32 slice_width, u32
num_slices)
+{
+ u32 bytes_target;
+
+ bytes_target = num_slices * DIV_ROUND_UP(dsc_bpp_x16 * slice_width,
+8 * BPP_MULTIPLIER);
+
+ return DIV_ROUND_UP(bytes_target, 3);
+}
+
+/* Get required no. of tribytes (estimate1) during HCBlank */
+static u32
+drm_get_frl_hcblank_tb_est1_target(u32 hcactive_target_tb,
+ u32 hactive, u32 hblank)
+{
+ return DIV_ROUND_UP(hcactive_target_tb * hblank, hactive);
+}
+
+/* Get required no. of tribytes during HCBlank */
+static u32
+drm_get_frl_hcblank_tb_target(u32 hcactive_target_tb, u32 hactive, u32 hblank,
+ u32 hcblank_audio_min, u32 cfrl_available)
+{
+ u32 hcblank_target_tb1 =
drm_get_frl_hcblank_tb_est1_target(hcactive_target_tb,
+ hactive,
hblank);
+ u32 hcblank_target_tb2 = max(hcblank_target_tb1, hcblank_audio_min);
+
+ return 4 * (min(hcblank_target_tb2,
+ (2 * cfrl_available - 3 * hcactive_target_tb) / 2) / 4);
+}
+
+/* Get the avg no of tribytes sent per sec (Kbps) */
+static u32
+drm_frl_dsc_get_ftb_avg(u32 hcactive_target_tb, u32 hcblank_target_tb,
+ u32 hactive, u32 hblank,
+ u32 fpixelclock_max_khz)
+{
+ return (hcactive_target_tb + hcblank_target_tb) *
+ (fpixelclock_max_khz / (hactive + hblank));
+}
+
+/* Time to send Active tribytes in nanoseconds */
+static u32
+drm_frl_dsc_get_tactive_ref_ns(u32 line_time_ns, u32 hactive, u32 hblank)
+{
+ return (line_time_ns * hactive) / (hactive + hblank);
+}
+
+/* Time to send Blanking tribytes in nanoseconds */
+static u32
+drm_frl_dsc_get_tblank_ref_ns(u32 line_time_ns, u32 hactive, u32 hblank)
+{
+ return (line_time_ns * hblank) / (hactive + hblank);
+}
+
+/* Get time to send all tribytes in hcactive region in nsec*/
+static u32
+drm_frl_dsc_tactive_target_ns(u32 frl_lanes, u32 hcactive_target_tb, u32
ftb_avg_k,
+ u32 min_frl_char_rate_k, u32 overhead_max)
+{
+ u32 avg_tribyte_time_ns, tribyte_time_ns;
+ u32 num_chars_hcactive;
+ u32 frl_char_rate_k;
+
+ /* Avg time to transmit all active region tribytes */
+ avg_tribyte_time_ns = (hcactive_target_tb * FRL_TIMING_NS_MULTIPLIER) /
+ (ftb_avg_k * 1000);
+
+ /*
+* 2 bytes in active region = 1 FRL characters
+* 1 Tribyte in active region = 3/2 FRL characters
+*/
+
+ num_chars_hcactive = (hcactive_target_tb * 3) / 2;
+
+ /*
+* FRL rate = lanes * frl character rate
+* But actual bandwidth wil be less, due to FRL limitations so account
+* for the overhead involved.
+* FRL rate with overhead = FRL rate * (100 - overhead %) / 100
+*/
+ frl_char_rate_k = frl_lanes * min_frl_char_rate_k;
+ frl_char_rate_k = (frl_char_rate_k * (EFFICIENCY_MULTIPLIER -
overhead_max)) /
+ EFFICIENCY_MULTIPLIER;
+
+ /* Time to transmit all characters with FRL limitations */
+ tribyte_time_ns = (num_chars_hcactive * FRL_TIMING_NS_MULTIPLIER) /
+ frl_char_rate_k * 1000;
+
+ return max(avg_tribyte_time_ns, tribyte_time_ns);
+}
+
+/* Get no. of tri bytes borrowed with DSC enabled */
+static u32
+drm_frl_get_dsc_tri_bytes_borrowed(u32 tactive_target_ns, u32 ftb_avg_k,
+ u32 hcactive_target_tb)
+{
+ return (tactive_target_ns * FRL_TIMING_NS_MULTIPLIER * ftb_avg_k *
1000) -
+ hcactive_target_tb;
+}
+
+/* Get TBdelta : borrowing in tribytes relative to avg tribyte rate */
+static u32
+drm_frl_get_dsc_tri_by
Re: [Intel-gfx] [PATCH] drm/i915/gt: fix unsigned integer to signed assignment
On Wed, Feb 16, 2022 at 11:02:06AM +0200, Jani Nikula wrote:
> On Wed, 16 Feb 2022, Jiapeng Chong wrote:
> > Eliminate the follow smatch warning:
> >
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4640
> > guc_create_virtual() warn: assigning (-2) to unsigned variable
> > 've->base.instance'.
> >
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4641
> > guc_create_virtual() warn: assigning (-2) to unsigned variable
> > 've->base.uabi_instance'.
> >
> > Reported-by: Abaci Robot
> > Signed-off-by: Jiapeng Chong
>
> The report seems to be valid, but I don't think this is the fix.
>
> Where do we even check for invalid instance/uabi_instance in code?
The whole thing seems rather poorly documented as there's a matching
uabi struct with __u16's and the negative values are defined right
there in the uapi header as well.
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 36365bdbe1ee..dc7cc06c68e7 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -328,10 +328,10 @@ struct intel_engine_cs {
> > intel_engine_mask_t logical_mask;
> >
> > u8 class;
> > - u8 instance;
> > + s8 instance;
> >
> > u16 uabi_class;
> > - u16 uabi_instance;
> > + s16 uabi_instance;
> >
> > u32 uabi_capabilities;
> > u32 context_size;
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Initialize GuC submission locks and queues early
== Series Details ==
Series: drm/i915/guc: Initialize GuC submission locks and queues early
URL : https://patchwork.freedesktop.org/series/100138/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11230_full -> Patchwork_22274_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22274_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22274_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
--
Missing(1): shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22274_full:
### IGT changes ###
Possible regressions
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-glk7/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_flush@basic-wb-set-default:
- {shard-rkl}:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/igt@gem_exec_fl...@basic-wb-set-default.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-5/igt@gem_exec_fl...@basic-wb-set-default.html
Known issues
Here are the changes found in Patchwork_22274_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- {shard-rkl}:([PASS][5], [PASS][6], [PASS][7], [FAIL][8],
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14],
[PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20]) ->
([PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26],
[PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32],
[PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38],
[PASS][39], [PASS][40])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-6/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-6/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-5/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-5/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-4/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-4/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-2/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-2/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-2/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-2/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-2/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-2/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22274/shard-rkl-1/boot.html
[34]:
https://intel-gfx-c
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Move intel_plane_atomic_calc_changes() & co. out
On Fri, 11 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Exfiltrate intel_plane_atomic_calc_changes() and its friends from
> intel_display.c to intel_atomic_plane.c since that is a much better
> fit.
>
> While at it also nuke the official looking kernel docs for
> intel_wm_need_update() and flag it for eventual destruction so
> that people don't get any wrong ideas about using it in new code.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 180 +
> .../gpu/drm/i915/display/intel_atomic_plane.h | 4 -
> drivers/gpu/drm/i915/display/intel_display.c | 188 --
> 3 files changed, 180 insertions(+), 192 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index bec02333bdeb..3355eb637eac 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -45,6 +45,7 @@
> #include "intel_fb_pin.h"
> #include "intel_pm.h"
> #include "intel_sprite.h"
> +#include "skl_scaler.h"
>
> static void intel_plane_state_reset(struct intel_plane_state *plane_state,
> struct intel_plane *plane)
> @@ -330,6 +331,185 @@ void intel_plane_set_invisible(struct intel_crtc_state
> *crtc_state,
> plane_state->uapi.visible = false;
> }
>
> +/* FIXME nuke when all wm code is atomic */
> +static bool intel_wm_need_update(const struct intel_plane_state *cur,
> + struct intel_plane_state *new)
> +{
> + /* Update watermarks on tiling or size changes. */
> + if (new->uapi.visible != cur->uapi.visible)
> + return true;
> +
> + if (!cur->hw.fb || !new->hw.fb)
> + return false;
> +
> + if (cur->hw.fb->modifier != new->hw.fb->modifier ||
> + cur->hw.rotation != new->hw.rotation ||
> + drm_rect_width(&new->uapi.src) != drm_rect_width(&cur->uapi.src) ||
> + drm_rect_height(&new->uapi.src) != drm_rect_height(&cur->uapi.src)
> ||
> + drm_rect_width(&new->uapi.dst) != drm_rect_width(&cur->uapi.dst) ||
> + drm_rect_height(&new->uapi.dst) != drm_rect_height(&cur->uapi.dst))
> + return true;
> +
> + return false;
> +}
> +
> +static bool intel_plane_is_scaled(const struct intel_plane_state
> *plane_state)
> +{
> + int src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
> + int src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
> + int dst_w = drm_rect_width(&plane_state->uapi.dst);
> + int dst_h = drm_rect_height(&plane_state->uapi.dst);
> +
> + return src_w != dst_w || src_h != dst_h;
> +}
> +
> +static bool intel_plane_do_async_flip(struct intel_plane *plane,
> + const struct intel_crtc_state
> *old_crtc_state,
> + const struct intel_crtc_state
> *new_crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(plane->base.dev);
> +
> + if (!plane->async_flip)
> + return false;
> +
> + if (!new_crtc_state->uapi.async_flip)
> + return false;
> +
> + /*
> + * In platforms after DISPLAY13, we might need to override
> + * first async flip in order to change watermark levels
> + * as part of optimization.
> + * So for those, we are checking if this is a first async flip.
> + * For platforms earlier than DISPLAY13 we always do async flip.
> + */
> + return DISPLAY_VER(i915) < 13 || old_crtc_state->uapi.async_flip;
> +}
> +
> +static int intel_plane_atomic_calc_changes(const struct intel_crtc_state
> *old_crtc_state,
> +struct intel_crtc_state
> *new_crtc_state,
> +const struct intel_plane_state
> *old_plane_state,
> +struct intel_plane_state
> *new_plane_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> + struct intel_plane *plane = to_intel_plane(new_plane_state->uapi.plane);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + bool mode_changed = intel_crtc_needs_modeset(new_crtc_state);
> + bool was_crtc_enabled = old_crtc_state->hw.active;
> + bool is_crtc_enabled = new_crtc_state->hw.active;
> + bool turn_off, turn_on, visible, was_visible;
> + int ret;
> +
> + if (DISPLAY_VER(dev_priv) >= 9 && plane->id != PLANE_CURSOR) {
> + ret = skl_update_scaler_plane(new_crtc_state, new_plane_state);
> + if (ret)
> + return ret;
> + }
> +
> + was_visible = old_plane_state->uapi.visible;
> + visible = new_plane_state->uapi.visible;
> +
> + if (!was_crtc_enabled && drm_WARN_ON(&dev_priv->drm, was_visible))
> + was_visible = false;
> +
> + /*
> + * Visibility is calculated as if th
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
On Wed, 2022-02-16 at 10:50 +0200, Ville Syrjälä wrote:
> On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote:
> > From: Jouni Högander
> >
> > Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E
> > port. Correct offset is 0x64C14.
>
> Why is it PHY_E and not PHY_F?
This is a valid question. It seems we have followed intel_phy_is_snps()
here:
// snip
else if (IS_DG2(dev_priv))
/*
* All four "combo" ports and the TC1 port (PHY E) use
* Synopsis PHYs.
*/
return phy <= PHY_E;
// snip
According to spec port E is "No connection". Better place to fix this
could be intel_phy_is_snps() itself?
>
> > Fix this by handling PHY_E port seprately.
> >
> > Signed-off-by: Matt Roper
> > Signed-off-by: Jouni Högander
> > Signed-off-by: Ramalingam C
> > ---
> > drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
> > drivers/gpu/drm/i915/i915_reg.h | 6 --
> > 2 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> > b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> > index c60575cb5368..f08061c748b3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> > @@ -32,7 +32,7 @@ void intel_snps_phy_wait_for_calibration(struct
> > drm_i915_private *i915)
> > if (!intel_phy_is_snps(i915, phy))
> > continue;
> >
> > - if (intel_de_wait_for_clear(i915, ICL_PHY_MISC(phy),
> > + if (intel_de_wait_for_clear(i915, DG2_PHY_MISC(phy),
> > DG2_PHY_DP_TX_ACK_MASK,
> > 25))
> > drm_err(&i915->drm, "SNPS PHY %c failed to
> > calibrate after 25ms.\n",
> > phy);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 4d12abb2d7ff..354c25f483cb 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9559,8 +9559,10 @@ enum skl_power_gate {
> >
> > #define _ICL_PHY_MISC_A0x64C00
> > #define _ICL_PHY_MISC_B0x64C04
> > -#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A, \
> > -_ICL_PHY_MISC_B)
> > +#define _DG2_PHY_MISC_TC1 0x64C14 /* TC1="PHY E" but offset as if
> > "PHY F" */
> > +#define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A,
> > _ICL_PHY_MISC_B)
> > +#define DG2_PHY_MISC(port) ((port) == PHY_E ?
> > _MMIO(_DG2_PHY_MISC_TC1) : \
> > +ICL_PHY_MISC(port))
> > #define ICL_PHY_MISC_MUX_DDID (1 << 28)
> > #define ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN (1 << 23)
> > #define DG2_PHY_DP_TX_ACK_MASKREG_GENMASK(23,
> > 20)
> > --
> > 2.20.1
BR,
Jouni Högander
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Introduce intel_arm_planes_on_crtc()
On Fri, 11 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No reason the high level intel_update_crtc() needs to know
> that there is something magical about the commit order of
> planes between different platforms. So let's hide that
> detail even better.
>
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 19 +++
> .../gpu/drm/i915/display/intel_atomic_plane.h | 6 ++
> drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> 3 files changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 3355eb637eac..bba2f105b7dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -716,8 +716,8 @@ void intel_update_planes_on_crtc(struct
> intel_atomic_state *state,
> }
> }
>
> -void skl_arm_planes_on_crtc(struct intel_atomic_state *state,
> - struct intel_crtc *crtc)
> +static void skl_arm_planes_on_crtc(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
> {
> struct intel_crtc_state *old_crtc_state =
> intel_atomic_get_old_crtc_state(state, crtc);
> @@ -751,8 +751,8 @@ void skl_arm_planes_on_crtc(struct intel_atomic_state
> *state,
> }
> }
>
> -void i9xx_arm_planes_on_crtc(struct intel_atomic_state *state,
> - struct intel_crtc *crtc)
> +static void i9xx_arm_planes_on_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> {
> struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> @@ -777,6 +777,17 @@ void i9xx_arm_planes_on_crtc(struct intel_atomic_state
> *state,
> }
> }
>
> +void intel_arm_planes_on_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
I don't much like the intel_arm_ prefix here. I'd go for intel_plane_
something or other.
Can be fixed while applying, or later. *shrug*
Reviewed-by: Jani Nikula
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> +
> + if (DISPLAY_VER(i915) >= 9)
> + skl_arm_planes_on_crtc(state, crtc);
> + else
> + i9xx_arm_planes_on_crtc(state, crtc);
> +}
> +
> int intel_atomic_plane_check_clipping(struct intel_plane_state *plane_state,
> struct intel_crtc_state *crtc_state,
> int min_scale, int max_scale,
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> index 9822b921279c..b7973e932e78 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> @@ -46,10 +46,8 @@ void intel_plane_destroy_state(struct drm_plane *plane,
> struct drm_plane_state *state);
> void intel_update_planes_on_crtc(struct intel_atomic_state *state,
>struct intel_crtc *crtc);
> -void skl_arm_planes_on_crtc(struct intel_atomic_state *state,
> - struct intel_crtc *crtc);
> -void i9xx_arm_planes_on_crtc(struct intel_atomic_state *state,
> - struct intel_crtc *crtc);
> +void intel_arm_planes_on_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc);
> int intel_plane_atomic_check_with_state(const struct intel_crtc_state
> *old_crtc_state,
> struct intel_crtc_state *crtc_state,
> const struct intel_plane_state
> *old_plane_state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3f68fb656fb5..aac1695657df 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7796,7 +7796,6 @@ static void intel_enable_crtc(struct intel_atomic_state
> *state,
> static void intel_update_crtc(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> {
> - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> const struct intel_crtc_state *old_crtc_state =
> intel_atomic_get_old_crtc_state(state, crtc);
> struct intel_crtc_state *new_crtc_state =
> @@ -7824,10 +7823,7 @@ static void intel_update_crtc(struct
> intel_atomic_state *state,
>
> commit_pipe_pre_planes(state, crtc);
>
> - if (DISPLAY_VER(dev_priv) >= 9)
> - skl_arm_planes_on_crtc(state, crtc);
> - else
> - i9xx_arm_planes_on_crtc(state, crtc);
> + intel_arm_planes_on_crtc(state, crtc);
>
> commit_pipe_post_planes(state, crtc);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Introduce scaled_planes bitmask
On Fri, 11 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add another plane bitmask, this time tracking which planes are
> scaled. This is going to be useful in ILK watermark computations,
> and skl+ pipe scaler assignments.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_atomic_plane.c | 5 +
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index bba2f105b7dd..79720bd5a485 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -323,6 +323,7 @@ void intel_plane_set_invisible(struct intel_crtc_state
> *crtc_state,
> struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
>
> crtc_state->active_planes &= ~BIT(plane->id);
> + crtc_state->scaled_planes &= ~BIT(plane->id);
> crtc_state->nv12_planes &= ~BIT(plane->id);
> crtc_state->c8_planes &= ~BIT(plane->id);
> crtc_state->data_rate[plane->id] = 0;
> @@ -536,6 +537,10 @@ int intel_plane_atomic_check_with_state(const struct
> intel_crtc_state *old_crtc_
> if (new_plane_state->uapi.visible)
> new_crtc_state->active_planes |= BIT(plane->id);
>
> + if (new_plane_state->uapi.visible &&
> + intel_plane_is_scaled(new_plane_state))
> + new_crtc_state->scaled_planes |= BIT(plane->id);
> +
> if (new_plane_state->uapi.visible &&
> intel_format_info_is_yuv_semiplanar(fb->format, fb->modifier))
> new_crtc_state->nv12_planes |= BIT(plane->id);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 60e15226a8cb..7a5c1e334449 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1168,6 +1168,7 @@ struct intel_crtc_state {
>
> /* bitmask of actually visible planes (enum plane_id) */
> u8 active_planes;
> + u8 scaled_planes;
> u8 nv12_planes;
> u8 c8_planes;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Use {active, scaled}_planes to compute ilk watermarks
On Fri, 11 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the {active,scaled}_planes bitmasks from the crtc state
> rather than poking at the plane state directly. One step
> towards eliminating the last use of the somewhat questionble
> intel_atomic_crtc_state_for_each_plane_state() macro which
> peeks into the plane state without actually holding the plane
> mutex.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_pm.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 4f2f0e80beef..0fa3dce9bd54 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3179,12 +3179,8 @@ static int ilk_compute_pipe_wm(struct
> intel_atomic_state *state,
> }
>
> pipe_wm->pipe_enabled = crtc_state->hw.active;
> - if (sprstate) {
> - pipe_wm->sprites_enabled = sprstate->uapi.visible;
> - pipe_wm->sprites_scaled = sprstate->uapi.visible &&
> - (drm_rect_width(&sprstate->uapi.dst) !=
> drm_rect_width(&sprstate->uapi.src) >> 16 ||
> - drm_rect_height(&sprstate->uapi.dst) !=
> drm_rect_height(&sprstate->uapi.src) >> 16);
> - }
> + pipe_wm->sprites_enabled = crtc_state->active_planes &
> BIT(PLANE_SPRITE0);
> + pipe_wm->sprites_scaled = crtc_state->scaled_planes &
> BIT(PLANE_SPRITE0);
>
> usable_level = max_level;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Remove gen6_check_mch_setup()
On Fri, 11 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> snb_wm_latency_quirk() already boosts up the latency values
> so the extra warning about the SSKPD value being insufficient
> is now redundant. Drop it.
>
> Signed-off-by: Ville Syrjälä
I just might not understand what's going on...
...but snb_wm_latency_quirk() is only called for display 6, not for ivb
where the check is also removed?
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_pm.c | 15 ---
> 1 file changed, 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0fa3dce9bd54..34e46a9b8300 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7432,17 +7432,6 @@ static void cpt_init_clock_gating(struct
> drm_i915_private *dev_priv)
> }
> }
>
> -static void gen6_check_mch_setup(struct drm_i915_private *dev_priv)
> -{
> - u32 tmp;
> -
> - tmp = intel_uncore_read(&dev_priv->uncore, MCH_SSKPD);
> - if ((tmp & MCH_SSKPD_WM0_MASK) != MCH_SSKPD_WM0_VAL)
> - drm_dbg_kms(&dev_priv->drm,
> - "Wrong MCH_SSKPD value: 0x%08x This can cause
> underruns.\n",
> - tmp);
> -}
> -
> static void gen6_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> u32 dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
> @@ -7500,8 +7489,6 @@ static void gen6_init_clock_gating(struct
> drm_i915_private *dev_priv)
> g4x_disable_trickle_feed(dev_priv);
>
> cpt_init_clock_gating(dev_priv);
> -
> - gen6_check_mch_setup(dev_priv);
> }
>
> static void lpt_init_clock_gating(struct drm_i915_private *dev_priv)
> @@ -7853,8 +7840,6 @@ static void ivb_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> if (!HAS_PCH_NOP(dev_priv))
> cpt_init_clock_gating(dev_priv);
> -
> - gen6_check_mch_setup(dev_priv);
> }
>
> static void vlv_init_clock_gating(struct drm_i915_private *dev_priv)
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/gt: fix unsigned integer to signed assignment
On 16/02/2022 09:19, Ville Syrjälä wrote:
On Wed, Feb 16, 2022 at 11:02:06AM +0200, Jani Nikula wrote:
On Wed, 16 Feb 2022, Jiapeng Chong wrote:
Eliminate the follow smatch warning:
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4640
guc_create_virtual() warn: assigning (-2) to unsigned variable
've->base.instance'.
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4641
guc_create_virtual() warn: assigning (-2) to unsigned variable
've->base.uabi_instance'.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
The report seems to be valid, but I don't think this is the fix.
Where do we even check for invalid instance/uabi_instance in code?
The whole thing seems rather poorly documented as there's a matching
uabi struct with __u16's and the negative values are defined right
there in the uapi header as well.
Negative ones are exception values to be used in conjunction with the virtual engine uapi
(see "DOC: Virtual Engine uAPI" and also comment next to
I915_CONTEXT_PARAM_ENGINES).
AFAIK assigning negative int to unsigned int is defined and fine.
Compiler does warn on comparisons which is why we have:
./gem/i915_gem_busy.c: if (id == (u16)I915_ENGINE_CLASS_INVALID)
./gem/i915_gem_busy.c: if (id == (u16)I915_ENGINE_CLASS_INVALID)
./gem/i915_gem_context.c: if (ci.engine_class ==
(u16)I915_ENGINE_CLASS_INVALID &&
./gem/i915_gem_context.c: ci.engine_instance ==
(u16)I915_ENGINE_CLASS_INVALID_NONE)
So I think no action needed here.
Regards,
Tvrtko
BR,
Jani.
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 36365bdbe1ee..dc7cc06c68e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -328,10 +328,10 @@ struct intel_engine_cs {
intel_engine_mask_t logical_mask;
u8 class;
- u8 instance;
+ s8 instance;
u16 uabi_class;
- u16 uabi_instance;
+ s16 uabi_instance;
u32 uabi_capabilities;
u32 context_size;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Add REG_GENMASK64() and REG_FIELD_GET64()
On Fri, 11 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We treat SSKPD as a 64 bit register. Add the support macros
> to define/extract bits in such registers.
>
> v2: Fix 32bit builds
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg_defs.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h
> b/drivers/gpu/drm/i915/i915_reg_defs.h
> index 34d37bbf08cd..d78d78fce431 100644
> --- a/drivers/gpu/drm/i915/i915_reg_defs.h
> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h
> @@ -37,6 +37,21 @@
>__is_constexpr(__low) && \
>((__low) < 0 || (__high) > 31 || (__low) >
> (__high)
>
> +/**
> + * REG_GENMASK64() - Prepare a continuous u64 bitmask
> + * @__high: 0-based high bit
> + * @__low: 0-based low bit
> + *
> + * Local wrapper for GENMASK_ULL() to force u64, with compile time checks.
> + *
> + * @return: Continuous bitmask from @__high to @__low, inclusive.
> + */
> +#define REG_GENMASK64(__high, __low) \
> + ((u64)(GENMASK_ULL(__high, __low) + \
> +BUILD_BUG_ON_ZERO(__is_constexpr(__high) && \
> + __is_constexpr(__low) && \
> + ((__low) < 0 || (__high) > 63 || (__low) >
> (__high)
> +
> /*
> * Local integer constant expression version of is_power_of_2().
> */
> @@ -71,6 +86,18 @@
> */
> #define REG_FIELD_GET(__mask, __val) ((u32)FIELD_GET(__mask, __val))
>
> +/**
> + * REG_FIELD_GET64() - Extract a u64 bitfield value
> + * @__mask: shifted mask defining the field's length and position
> + * @__val: value to extract the bitfield value from
> + *
> + * Local wrapper for FIELD_GET() to force u64 and for consistency with
> + * REG_GENMASK64().
> + *
> + * @return: Masked and shifted value of the field defined by @__mask in
> @__val.
> + */
> +#define REG_FIELD_GET64(__mask, __val) ((u64)FIELD_GET(__mask, __val))
> +
> typedef struct {
> u32 reg;
> } i915_reg_t;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
On Wed, Feb 16, 2022 at 09:36:02AM +, Hogander, Jouni wrote: > On Wed, 2022-02-16 at 10:50 +0200, Ville Syrjälä wrote: > > On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote: > > > From: Jouni Högander > > > > > > Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E > > > port. Correct offset is 0x64C14. > > > > Why is it PHY_E and not PHY_F? > > This is a valid question. It seems we have followed intel_phy_is_snps() > here: > > // snip > else if (IS_DG2(dev_priv)) > /* >* All four "combo" ports and the TC1 port (PHY E) use >* Synopsis PHYs. >*/ > return phy <= PHY_E; > // snip > > According to spec port E is "No connection". Better place to fix this > could be intel_phy_is_snps() itself? I think the crucial question is where are all the places that the results of intel_port_to_phy() get used. I do see that for all the actual snps phy registers we do want PHY_E, but maybe it would be better to have a local SNPS_PHY enum just for intel_snps_phy.c, and leave the other phy thing for everything else? Not sure if there is some other register we index with the phy that specifically wants PHY_E? Also it kinda looks to me like for VBT port mapping we also want PHY_F essentially since the modern platforms make the VBT port mapping PHY based and xelpd_port_mapping() uses PORT_TC1<->DVO_PORT_*F. Not that we actually use enum phy in the VBT code atm, but I'm thinking we probably should since it might allow us to get rid of all those different mapping tables. Though the whole intel_port_to_phy() disaster needs to get cleaned up first IMO. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Remove gen6_check_mch_setup()
On Wed, Feb 16, 2022 at 11:54:00AM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > snb_wm_latency_quirk() already boosts up the latency values
> > so the extra warning about the SSKPD value being insufficient
> > is now redundant. Drop it.
> >
> > Signed-off-by: Ville Syrjälä
>
> I just might not understand what's going on...
>
> ...but snb_wm_latency_quirk() is only called for display 6, not for ivb
> where the check is also removed?
Hmm. Not sure this was ever an issue on IVB. I think the BIOSen
might have gotten all fixed by that time. Not sure. I guess we can
keep this for now. And maybe I should just rewrite to look at the
parsed latency values instead...
>
> BR,
> Jani.
>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 15 ---
> > 1 file changed, 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 0fa3dce9bd54..34e46a9b8300 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7432,17 +7432,6 @@ static void cpt_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> > }
> > }
> >
> > -static void gen6_check_mch_setup(struct drm_i915_private *dev_priv)
> > -{
> > - u32 tmp;
> > -
> > - tmp = intel_uncore_read(&dev_priv->uncore, MCH_SSKPD);
> > - if ((tmp & MCH_SSKPD_WM0_MASK) != MCH_SSKPD_WM0_VAL)
> > - drm_dbg_kms(&dev_priv->drm,
> > - "Wrong MCH_SSKPD value: 0x%08x This can cause
> > underruns.\n",
> > - tmp);
> > -}
> > -
> > static void gen6_init_clock_gating(struct drm_i915_private *dev_priv)
> > {
> > u32 dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
> > @@ -7500,8 +7489,6 @@ static void gen6_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> > g4x_disable_trickle_feed(dev_priv);
> >
> > cpt_init_clock_gating(dev_priv);
> > -
> > - gen6_check_mch_setup(dev_priv);
> > }
> >
> > static void lpt_init_clock_gating(struct drm_i915_private *dev_priv)
> > @@ -7853,8 +7840,6 @@ static void ivb_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> >
> > if (!HAS_PCH_NOP(dev_priv))
> > cpt_init_clock_gating(dev_priv);
> > -
> > - gen6_check_mch_setup(dev_priv);
> > }
> >
> > static void vlv_init_clock_gating(struct drm_i915_private *dev_priv)
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Clean up SSKPD/MLTR defines
On Fri, 11 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Give names to the SSKPD/MLTR fields, and use the
> REG_GENMASK* and REG_FIELD_GET*.
>
> Also drop the bogus non-mirrored SSKP register define.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 27 ---
> drivers/gpu/drm/i915/intel_pm.c | 24
> 2 files changed, 24 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 87c92314ee26..278c9cbc6f3c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1896,10 +1896,17 @@
> #define MAD_DIMM_A_SIZE_SHIFT 0
> #define MAD_DIMM_A_SIZE_MASK (0xff << MAD_DIMM_A_SIZE_SHIFT)
>
> -/* snb MCH registers for priority tuning */
> #define MCH_SSKPD_MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5d10)
> -#define MCH_SSKPD_WM0_MASK 0x3f
> -#define MCH_SSKPD_WM0_VAL 0xc
> +#define SSKPD_NEW_WM0_MASK_HSW REG_GENMASK64(63, 56)
> +#define SSKPD_WM4_MASK_HSW REG_GENMASK64(40, 32)
> +#define SSKPD_WM3_MASK_HSW REG_GENMASK64(28, 20)
> +#define SSKPD_WM2_MASK_HSW REG_GENMASK64(19, 12)
> +#define SSKPD_WM1_MASK_HSW REG_GENMASK64(11, 4)
> +#define SSKPD_OLD_WM0_MASK_HSW REG_GENMASK64(3, 0)
> +#define SSKPD_WM3_MASK_SNB REG_GENMASK(29, 24)
> +#define SSKPD_WM2_MASK_SNB REG_GENMASK(21, 16)
> +#define SSKPD_WM1_MASK_SNB REG_GENMASK(13, 8)
> +#define SSKPD_WM0_MASK_SNB REG_GENMASK(5, 0)
>
> /* Clocking configuration register */
> #define CLKCFG _MMIO(MCHBAR_MIRROR_BASE + 0xc00)
> @@ -4321,19 +4328,9 @@
>
> /* Memory latency timer register */
> #define MLTR_ILK _MMIO(0x11222)
> -#define MLTR_WM1_SHIFT 0
> -#define MLTR_WM2_SHIFT 8
> /* the unit of memory self-refresh latency time is 0.5us */
> -#define ILK_SRLT_MASK 0x3f
> -
> -
> -/* the address where we get all kinds of latency value */
> -#define SSKPD_MMIO(0x5d10)
> -#define SSKPD_WM_MASK0x3f
> -#define SSKPD_WM0_SHIFT 0
> -#define SSKPD_WM1_SHIFT 8
> -#define SSKPD_WM2_SHIFT 16
> -#define SSKPD_WM3_SHIFT 24
> +#define MLTR_WM2_MASK REG_GENMASK(13, 8)
> +#define MLTR_WM1_MASK REG_GENMASK(5, 0)
>
> /*
> * The two pipe frame counter registers are not synchronized, so
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 34e46a9b8300..605944551e1b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2946,27 +2946,27 @@ static void intel_read_wm_latency(struct
> drm_i915_private *dev_priv,
> } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> u64 sskpd = intel_uncore_read64(uncore, MCH_SSKPD);
>
> - wm[0] = (sskpd >> 56) & 0xFF;
> + wm[0] = REG_FIELD_GET64(SSKPD_NEW_WM0_MASK_HSW, sskpd);
> if (wm[0] == 0)
> - wm[0] = sskpd & 0xF;
> - wm[1] = (sskpd >> 4) & 0xFF;
> - wm[2] = (sskpd >> 12) & 0xFF;
> - wm[3] = (sskpd >> 20) & 0x1FF;
> - wm[4] = (sskpd >> 32) & 0x1FF;
> + wm[0] = REG_FIELD_GET64(SSKPD_OLD_WM0_MASK_HSW, sskpd);
> + wm[1] = REG_FIELD_GET64(SSKPD_WM1_MASK_HSW, sskpd);
> + wm[2] = REG_FIELD_GET64(SSKPD_WM2_MASK_HSW, sskpd);
> + wm[3] = REG_FIELD_GET64(SSKPD_WM3_MASK_HSW, sskpd);
> + wm[4] = REG_FIELD_GET64(SSKPD_WM4_MASK_HSW, sskpd);
> } else if (DISPLAY_VER(dev_priv) >= 6) {
> u32 sskpd = intel_uncore_read(uncore, MCH_SSKPD);
>
> - wm[0] = (sskpd >> SSKPD_WM0_SHIFT) & SSKPD_WM_MASK;
> - wm[1] = (sskpd >> SSKPD_WM1_SHIFT) & SSKPD_WM_MASK;
> - wm[2] = (sskpd >> SSKPD_WM2_SHIFT) & SSKPD_WM_MASK;
> - wm[3] = (sskpd >> SSKPD_WM3_SHIFT) & SSKPD_WM_MASK;
> + wm[0] = REG_FIELD_GET(SSKPD_WM0_MASK_SNB, sskpd);
> + wm[1] = REG_FIELD_GET(SSKPD_WM1_MASK_SNB, sskpd);
> + wm[2] = REG_FIELD_GET(SSKPD_WM2_MASK_SNB, sskpd);
> + wm[3] = REG_FIELD_GET(SSKPD_WM3_MASK_SNB, sskpd);
> } else if (DISPLAY_VER(dev_priv) >= 5) {
> u32 mltr = intel_uncore_read(uncore, MLTR_ILK);
>
> /* ILK primary LP0 latency is 700 ns */
> wm[0] = 7;
> - wm[1] = (mltr >> MLTR_WM1_SHIFT) & ILK_SRLT_MASK;
> - wm[2] = (mltr >> MLTR_WM2_SHIFT) & ILK_SRLT_MASK;
> + wm[1] = REG_FIELD_GET(MLTR_WM1_MASK, mltr);
> + wm[2] = REG_FIELD_GET(MLTR_WM2_MASK, mltr);
> } else {
> MISSING_CASE(INTEL_DEVID(dev_priv));
> }
--
Jani Nikula, Intel O
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/perf: Skip the i915_perf_init for dg2
== Series Details ==
Series: drm/i915/perf: Skip the i915_perf_init for dg2
URL : https://patchwork.freedesktop.org/series/100150/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11230_full -> Patchwork_22276_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22276_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22276_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
--
Missing(1): shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22276_full:
### IGT changes ###
Possible regressions
* igt@gem_workarounds@suspend-resume-fd:
- shard-skl: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22276/shard-skl9/igt@gem_workarou...@suspend-resume-fd.html
* igt@kms_cursor_legacy@cursor-vs-flip-legacy:
- shard-iclb: [PASS][2] -> [FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-iclb7/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22276/shard-iclb7/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- shard-glk: [PASS][4] -> [FAIL][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22276/shard-glk6/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_shared@q-smoketest@vcs0:
- {shard-rkl}:([PASS][6], [PASS][7]) -> [DMESG-WARN][8]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@gem_ctx_shared@q-smoket...@vcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/igt@gem_ctx_shared@q-smoket...@vcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22276/shard-rkl-5/igt@gem_ctx_shared@q-smoket...@vcs0.html
* igt@gem_exec_flush@basic-uc-pro-default:
- {shard-rkl}:NOTRUN -> [DMESG-WARN][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22276/shard-rkl-5/igt@gem_exec_fl...@basic-uc-pro-default.html
* igt@kms_cursor_legacy@cursora-vs-flipb-legacy:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][10] +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22276/shard-rkl-5/igt@kms_cursor_leg...@cursora-vs-flipb-legacy.html
Known issues
Here are the changes found in Patchwork_22276_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- {shard-rkl}:([PASS][11], [PASS][12], [PASS][13], [FAIL][14],
[PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20],
[PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26]) ->
([PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32],
[PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38],
[PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44],
[PASS][45])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-t
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Polish ilk+ wm register bits
On Fri, 11 Feb 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Use REG_GENMASK() & co. for ilk+ watermarm registers. *watermark > > Signed-off-by: Ville Syrjälä > --- > .../drm/i915/display/intel_display_debugfs.c | 2 +- > drivers/gpu/drm/i915/i915_reg.h | 41 +++-- > drivers/gpu/drm/i915/intel_pm.c | 57 +-- > 3 files changed, 49 insertions(+), 51 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > index f4de004d470f..b219e162f1d1 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c > @@ -78,7 +78,7 @@ static int i915_sr_status(struct seq_file *m, void *unused) > if (DISPLAY_VER(dev_priv) >= 9) > /* no global SR status; inspect per-plane WM */; > else if (HAS_PCH_SPLIT(dev_priv)) > - sr_enabled = intel_de_read(dev_priv, WM1_LP_ILK) & WM1_LP_SR_EN; > + sr_enabled = intel_de_read(dev_priv, WM1_LP_ILK) & WM_LP_ENABLE; > else if (IS_I965GM(dev_priv) || IS_G4X(dev_priv) || >IS_I945G(dev_priv) || IS_I945GM(dev_priv)) > sr_enabled = intel_de_read(dev_priv, FW_BLC_SELF) & > FW_BLC_SELF_EN; > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 278c9cbc6f3c..0dd4d34e7cd7 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -4298,33 +4298,32 @@ > #define _WM0_PIPEC_IVB 0x45200 > #define WM0_PIPE_ILK(pipe) _MMIO_PIPE3((pipe), _WM0_PIPEA_ILK, \ > _WM0_PIPEB_ILK, _WM0_PIPEC_IVB) > -#define WM0_PIPE_PLANE_MASK (0x << 16) > -#define WM0_PIPE_PLANE_SHIFT16 > -#define WM0_PIPE_SPRITE_MASK(0xff << 8) > -#define WM0_PIPE_SPRITE_SHIFT 8 > -#define WM0_PIPE_CURSOR_MASK(0xff) > +#define WM0_PIPE_PRIMARY_MASK REG_GENMASK(23, 16) Should be (31,16) to match current WM0_PIPE_PLANE_MASK. I didn't try to find the bspec, but if this is an intentional fix, should be split out to a separate patch. Other than that, Reviewed-by: Jani Nikula > +#define WM0_PIPE_SPRITE_MASKREG_GENMASK(15, 8) > +#define WM0_PIPE_CURSOR_MASKREG_GENMASK(5, 0) > +#define WM0_PIPE_PRIMARY(x) REG_FIELD_PREP(WM0_PIPE_PRIMARY_MASK, (x)) > +#define WM0_PIPE_SPRITE(x) REG_FIELD_PREP(WM0_PIPE_SPRITE_MASK, (x)) > +#define WM0_PIPE_CURSOR(x) REG_FIELD_PREP(WM0_PIPE_CURSOR_MASK, (x)) > #define WM1_LP_ILK _MMIO(0x45108) > -#define WM1_LP_SR_EN(1 << 31) > -#define WM1_LP_LATENCY_SHIFT24 > -#define WM1_LP_LATENCY_MASK (0x7f << 24) > -#define WM1_LP_FBC_MASK (0xf << 20) > -#define WM1_LP_FBC_SHIFT20 > -#define WM1_LP_FBC_SHIFT_BDW19 > -#define WM1_LP_SR_MASK (0x7ff << 8) > -#define WM1_LP_SR_SHIFT 8 > -#define WM1_LP_CURSOR_MASK (0xff) > #define WM2_LP_ILK _MMIO(0x4510c) > -#define WM2_LP_EN (1 << 31) > #define WM3_LP_ILK _MMIO(0x45110) > -#define WM3_LP_EN (1 << 31) > +#define WM_LP_ENABLEREG_BIT(31) > +#define WM_LP_LATENCY_MASK REG_GENMASK(30, 24) > +#define WM_LP_FBC_MASK_BDW REG_GENMASK(23, 19) > +#define WM_LP_FBC_MASK_ILK REG_GENMASK(23, 20) > +#define WM_LP_PRIMARY_MASK REG_GENMASK(18, 8) > +#define WM_LP_CURSOR_MASK REG_GENMASK(7, 0) > +#define WM_LP_LATENCY(x)REG_FIELD_PREP(WM_LP_LATENCY_MASK, (x)) > +#define WM_LP_FBC_BDW(x)REG_FIELD_PREP(WM_LP_FBC_MASK_BDW, (x)) > +#define WM_LP_FBC_ILK(x)REG_FIELD_PREP(WM_LP_FBC_MASK_ILK, (x)) > +#define WM_LP_PRIMARY(x)REG_FIELD_PREP(WM_LP_PRIMARY_MASK, (x)) > +#define WM_LP_CURSOR(x) REG_FIELD_PREP(WM_LP_CURSOR_MASK, (x)) > #define WM1S_LP_ILK _MMIO(0x45120) > #define WM2S_LP_IVB _MMIO(0x45124) > #define WM3S_LP_IVB _MMIO(0x45128) > -#define WM1S_LP_EN (1 << 31) > - > -#define HSW_WM_LP_VAL(lat, fbc, pri, cur) \ > - (WM3_LP_EN | ((lat) << WM1_LP_LATENCY_SHIFT) | \ > - ((fbc) << WM1_LP_FBC_SHIFT) | ((pri) << WM1_LP_SR_SHIFT) | (cur)) > +#define WM_LP_SPRITE_ENABLE REG_BIT(31) /* ilk/snb WM1S only */ > +#define WM_LP_SPRITE_MASK REG_GENMASK(10, 0) > +#define WM_LP_SPRITE(x) REG_FIELD_PREP(WM_LP_SPRITE_MASK, (x)) > > /* Memory latency timer register */ > #define MLTR_ILK _MMIO(0x11222) > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 605944551e1b..9382284134e6 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3409,29 +3409,28 @@ static void ilk_compute_wm_results(struct > drm_i915_private *dev_priv, >* disabled. Doing otherwise could cause underruns. >*/ > results->wm_lp[wm_lp - 1] = > - (ilk_wm_lp_latency(dev_priv, lev
Re: [Intel-gfx] [PATCH] drm/i915/gt: fix unsigned integer to signed assignment
On Wed, 16 Feb 2022, Tvrtko Ursulin wrote:
> On 16/02/2022 09:19, Ville Syrjälä wrote:
>> On Wed, Feb 16, 2022 at 11:02:06AM +0200, Jani Nikula wrote:
>>> On Wed, 16 Feb 2022, Jiapeng Chong wrote:
Eliminate the follow smatch warning:
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4640
guc_create_virtual() warn: assigning (-2) to unsigned variable
've->base.instance'.
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4641
guc_create_virtual() warn: assigning (-2) to unsigned variable
've->base.uabi_instance'.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
>>>
>>> The report seems to be valid, but I don't think this is the fix.
>>>
>>> Where do we even check for invalid instance/uabi_instance in code?
>>
>> The whole thing seems rather poorly documented as there's a matching
>> uabi struct with __u16's and the negative values are defined right
>> there in the uapi header as well.
>
> Negative ones are exception values to be used in conjunction with the virtual
> engine uapi (see "DOC: Virtual Engine uAPI" and also comment next to
> I915_CONTEXT_PARAM_ENGINES).
>
> AFAIK assigning negative int to unsigned int is defined and fine.
>
> Compiler does warn on comparisons which is why we have:
>
> ./gem/i915_gem_busy.c: if (id == (u16)I915_ENGINE_CLASS_INVALID)
> ./gem/i915_gem_busy.c: if (id == (u16)I915_ENGINE_CLASS_INVALID)
> ./gem/i915_gem_context.c: if (ci.engine_class ==
> (u16)I915_ENGINE_CLASS_INVALID &&
> ./gem/i915_gem_context.c: ci.engine_instance ==
> (u16)I915_ENGINE_CLASS_INVALID_NONE)
>
> So I think no action needed here.
We never check instance or uabi_instance members against
I915_ENGINE_CLASS_INVALID_VIRTUAL anywhere.
BR,
Jani.
>
> Regards,
>
> Tvrtko
>
>>>
>>> BR,
>>> Jani.
>>>
>>>
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 36365bdbe1ee..dc7cc06c68e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -328,10 +328,10 @@ struct intel_engine_cs {
intel_engine_mask_t logical_mask;
u8 class;
- u8 instance;
+ s8 instance;
u16 uabi_class;
- u16 uabi_instance;
+ s16 uabi_instance;
u32 uabi_capabilities;
u32 context_size;
>>>
>>> --
>>> Jani Nikula, Intel Open Source Graphics Center
>>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Polish ilk+ wm register bits
On Wed, Feb 16, 2022 at 12:29:52PM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use REG_GENMASK() & co. for ilk+ watermarm registers.
>
> *watermark
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../drm/i915/display/intel_display_debugfs.c | 2 +-
> > drivers/gpu/drm/i915/i915_reg.h | 41 +++--
> > drivers/gpu/drm/i915/intel_pm.c | 57 +--
> > 3 files changed, 49 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index f4de004d470f..b219e162f1d1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -78,7 +78,7 @@ static int i915_sr_status(struct seq_file *m, void
> > *unused)
> > if (DISPLAY_VER(dev_priv) >= 9)
> > /* no global SR status; inspect per-plane WM */;
> > else if (HAS_PCH_SPLIT(dev_priv))
> > - sr_enabled = intel_de_read(dev_priv, WM1_LP_ILK) & WM1_LP_SR_EN;
> > + sr_enabled = intel_de_read(dev_priv, WM1_LP_ILK) & WM_LP_ENABLE;
> > else if (IS_I965GM(dev_priv) || IS_G4X(dev_priv) ||
> > IS_I945G(dev_priv) || IS_I945GM(dev_priv))
> > sr_enabled = intel_de_read(dev_priv, FW_BLC_SELF) &
> > FW_BLC_SELF_EN;
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 278c9cbc6f3c..0dd4d34e7cd7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4298,33 +4298,32 @@
> > #define _WM0_PIPEC_IVB 0x45200
> > #define WM0_PIPE_ILK(pipe) _MMIO_PIPE3((pipe), _WM0_PIPEA_ILK, \
> > _WM0_PIPEB_ILK, _WM0_PIPEC_IVB)
> > -#define WM0_PIPE_PLANE_MASK (0x << 16)
> > -#define WM0_PIPE_PLANE_SHIFT 16
> > -#define WM0_PIPE_SPRITE_MASK (0xff << 8)
> > -#define WM0_PIPE_SPRITE_SHIFT 8
> > -#define WM0_PIPE_CURSOR_MASK (0xff)
> > +#define WM0_PIPE_PRIMARY_MASK REG_GENMASK(23, 16)
>
> Should be (31,16) to match current WM0_PIPE_PLANE_MASK.
>
> I didn't try to find the bspec, but if this is an intentional fix,
> should be split out to a separate patch.
Right. Forgot that I refined the bitfield sizes here. I'll
split that part out.
An easy way to double check these w/o a spec is
ilk_{plane,cursor}_wm_reg_max(). Assuming those are correct
of course :) Hmm, I guess I could also think about rewriting
those to use the *_MASK defines. Though I'd have to define
separate masks for each platform variant...
>
> Other than that,
>
> Reviewed-by: Jani Nikula
Thanks.
>
> > +#define WM0_PIPE_SPRITE_MASK REG_GENMASK(15, 8)
> > +#define WM0_PIPE_CURSOR_MASK REG_GENMASK(5, 0)
> > +#define WM0_PIPE_PRIMARY(x) REG_FIELD_PREP(WM0_PIPE_PRIMARY_MASK,
> > (x))
> > +#define WM0_PIPE_SPRITE(x)REG_FIELD_PREP(WM0_PIPE_SPRITE_MASK,
> > (x))
> > +#define WM0_PIPE_CURSOR(x)REG_FIELD_PREP(WM0_PIPE_CURSOR_MASK,
> > (x))
> > #define WM1_LP_ILK _MMIO(0x45108)
> > -#define WM1_LP_SR_EN (1 << 31)
> > -#define WM1_LP_LATENCY_SHIFT 24
> > -#define WM1_LP_LATENCY_MASK (0x7f << 24)
> > -#define WM1_LP_FBC_MASK (0xf << 20)
> > -#define WM1_LP_FBC_SHIFT 20
> > -#define WM1_LP_FBC_SHIFT_BDW 19
> > -#define WM1_LP_SR_MASK(0x7ff << 8)
> > -#define WM1_LP_SR_SHIFT 8
> > -#define WM1_LP_CURSOR_MASK(0xff)
> > #define WM2_LP_ILK _MMIO(0x4510c)
> > -#define WM2_LP_EN (1 << 31)
> > #define WM3_LP_ILK _MMIO(0x45110)
> > -#define WM3_LP_EN (1 << 31)
> > +#define WM_LP_ENABLE REG_BIT(31)
> > +#define WM_LP_LATENCY_MASKREG_GENMASK(30, 24)
> > +#define WM_LP_FBC_MASK_BDWREG_GENMASK(23, 19)
> > +#define WM_LP_FBC_MASK_ILKREG_GENMASK(23, 20)
> > +#define WM_LP_PRIMARY_MASKREG_GENMASK(18, 8)
> > +#define WM_LP_CURSOR_MASK REG_GENMASK(7, 0)
> > +#define WM_LP_LATENCY(x) REG_FIELD_PREP(WM_LP_LATENCY_MASK, (x))
> > +#define WM_LP_FBC_BDW(x) REG_FIELD_PREP(WM_LP_FBC_MASK_BDW, (x))
> > +#define WM_LP_FBC_ILK(x) REG_FIELD_PREP(WM_LP_FBC_MASK_ILK, (x))
> > +#define WM_LP_PRIMARY(x) REG_FIELD_PREP(WM_LP_PRIMARY_MASK, (x))
> > +#define WM_LP_CURSOR(x) REG_FIELD_PREP(WM_LP_CURSOR_MASK, (x))
> > #define WM1S_LP_ILK_MMIO(0x45120)
> > #define WM2S_LP_IVB_MMIO(0x45124)
> > #define WM3S_LP_IVB_MMIO(0x45128)
> > -#define WM1S_LP_EN(1 << 31)
> > -
> > -#define HSW_WM_LP_VAL(lat, fbc, pri, cur) \
> > - (WM3_LP_EN | ((lat) << WM1_LP_LATENCY_SHIFT) | \
> > -((fbc) << WM1_LP_FBC_SHIFT) | ((pri) << WM1_LP_SR_SHIFT) | (cur))
> > +#define WM_LP_SPRITE_ENABLE REG_BIT(31) /* ilk/snb WM1S only */
> > +#define WM_LP_SPRITE_MASK REG_GENMASK(10, 0)
>
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Eliminate bigjoiner boolean
On 2/16/2022 12:02 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Since we now have the bigjoiner_pipes bitmask the boolean
is redundant. Get rid of it.
Also, populating bigjoiner_pipes already during
encoder->compute_config() allows us to use it much earlier
during the state calculation as well. The initial aim is
to use it in intel_crtc_compute_config().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 50 ---
.../drm/i915/display/intel_display_debugfs.c | 2 +-
.../drm/i915/display/intel_display_types.h| 3 --
drivers/gpu/drm/i915/display/intel_dp.c | 13 ++---
drivers/gpu/drm/i915/display/intel_vdsc.c | 8 +--
.../drm/i915/display/skl_universal_plane.c| 2 +-
7 files changed, 36 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 1f448f4e9aaf..da6cf0515164 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -640,7 +640,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
* FIXME bigjoiner fastpath would be good
*/
if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
- crtc_state->update_pipe || crtc_state->bigjoiner)
+ crtc_state->update_pipe || crtc_state->bigjoiner_pipes)
goto slow;
/*
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 47b5d8cc16fd..192474163edb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1926,7 +1926,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
if (drm_WARN_ON(&dev_priv->drm, crtc->active))
return;
- if (!new_crtc_state->bigjoiner) {
+ if (!new_crtc_state->bigjoiner_pipes) {
intel_encoders_pre_pll_enable(state, crtc);
if (new_crtc_state->shared_dpll)
@@ -2727,7 +2727,7 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
*crtc_state,
struct drm_display_mode *mode)
{
- if (!crtc_state->bigjoiner)
+ if (!crtc_state->bigjoiner_pipes)
return;
mode->crtc_clock /= 2;
@@ -2811,7 +2811,7 @@ static void intel_bigjoiner_compute_pipe_src(struct
intel_crtc_state *crtc_state
{
int width, height;
- if (!crtc_state->bigjoiner)
+ if (!crtc_state->bigjoiner_pipes)
return;
width = drm_rect_width(&crtc_state->pipe_src);
@@ -4218,7 +4218,6 @@ static void intel_bigjoiner_get_config(struct
intel_crtc_state *crtc_state)
if (((master_pipes | slave_pipes) & BIT(pipe)) == 0)
return;
- crtc_state->bigjoiner = true;
crtc_state->bigjoiner_pipes =
BIT(get_bigjoiner_master_pipe(pipe, master_pipes, slave_pipes))
|
get_bigjoiner_slave_pipes(pipe, master_pipes, slave_pipes);
Although not part of this patch, do we need to check if
get_bigjoiner_master_pipe() does not give PIPE_INVALID?
Perhaps in a case where master_pipe is read as 0 but some garbage for
slave_pipes during readout?
Should there be a check for INVALID_PIPE, before feeding into BIT() macro?
Otherwise patch looks good to me.
Regards,
Ankit
@@ -5804,6 +5803,9 @@ copy_bigjoiner_crtc_state_modeset(struct
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, master_crtc);
struct intel_crtc_state *saved_state;
+ WARN_ON(master_crtc_state->bigjoiner_pipes !=
+ slave_crtc_state->bigjoiner_pipes);
+
saved_state = kmemdup(master_crtc_state, sizeof(*saved_state),
GFP_KERNEL);
if (!saved_state)
return -ENOMEM;
@@ -5834,6 +5836,9 @@ copy_bigjoiner_crtc_state_modeset(struct
intel_atomic_state *state,
slave_crtc_state->uapi.connectors_changed =
master_crtc_state->uapi.connectors_changed;
slave_crtc_state->uapi.active_changed =
master_crtc_state->uapi.active_changed;
+ WARN_ON(master_crtc_state->bigjoiner_pipes !=
+ slave_crtc_state->bigjoiner_pipes);
+
return 0;
}
@@ -6604,7 +6609,6 @@ intel_pipe_config_compare(const struct intel_crtc_state *current_config,
PIPE_CONF_CHECK_X(sync_mode_slaves_mask);
PIPE_CONF_CHECK_I(master_transcoder);
- PIPE_CONF_CHECK_BOOL(bigjoiner);
PIPE_CONF_CHECK_X(bigjoiner_pipes);
PIPE_CONF_CHECK_I(dsc.compression_enable);
@@ -7535,32 +7539,26 @@ static int intel_atomic_check_bigjoiner(struct
intel_atomic_state *state,
struct intel_crtc_state *master_crtc_state =
intel_atomic_get_new_crtc_state(state, master_crtc);
struct intel_crtc *slave_crtc;
-
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Eliminate bigjoiner boolean
On Wed, Feb 16, 2022 at 04:27:49PM +0530, Nautiyal, Ankit K wrote:
>
> On 2/16/2022 12:02 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Since we now have the bigjoiner_pipes bitmask the boolean
> > is redundant. Get rid of it.
> >
> > Also, populating bigjoiner_pipes already during
> > encoder->compute_config() allows us to use it much earlier
> > during the state calculation as well. The initial aim is
> > to use it in intel_crtc_compute_config().
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 50 ---
> > .../drm/i915/display/intel_display_debugfs.c | 2 +-
> > .../drm/i915/display/intel_display_types.h| 3 --
> > drivers/gpu/drm/i915/display/intel_dp.c | 13 ++---
> > drivers/gpu/drm/i915/display/intel_vdsc.c | 8 +--
> > .../drm/i915/display/skl_universal_plane.c| 2 +-
> > 7 files changed, 36 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> > b/drivers/gpu/drm/i915/display/intel_cursor.c
> > index 1f448f4e9aaf..da6cf0515164 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > @@ -640,7 +640,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> > * FIXME bigjoiner fastpath would be good
> > */
> > if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
> > - crtc_state->update_pipe || crtc_state->bigjoiner)
> > + crtc_state->update_pipe || crtc_state->bigjoiner_pipes)
> > goto slow;
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 47b5d8cc16fd..192474163edb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1926,7 +1926,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
> > *state,
> > if (drm_WARN_ON(&dev_priv->drm, crtc->active))
> > return;
> >
> > - if (!new_crtc_state->bigjoiner) {
> > + if (!new_crtc_state->bigjoiner_pipes) {
> > intel_encoders_pre_pll_enable(state, crtc);
> >
> > if (new_crtc_state->shared_dpll)
> > @@ -2727,7 +2727,7 @@ static void intel_crtc_compute_pixel_rate(struct
> > intel_crtc_state *crtc_state)
> > static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
> > *crtc_state,
> >struct drm_display_mode *mode)
> > {
> > - if (!crtc_state->bigjoiner)
> > + if (!crtc_state->bigjoiner_pipes)
> > return;
> >
> > mode->crtc_clock /= 2;
> > @@ -2811,7 +2811,7 @@ static void intel_bigjoiner_compute_pipe_src(struct
> > intel_crtc_state *crtc_state
> > {
> > int width, height;
> >
> > - if (!crtc_state->bigjoiner)
> > + if (!crtc_state->bigjoiner_pipes)
> > return;
> >
> > width = drm_rect_width(&crtc_state->pipe_src);
> > @@ -4218,7 +4218,6 @@ static void intel_bigjoiner_get_config(struct
> > intel_crtc_state *crtc_state)
> > if (((master_pipes | slave_pipes) & BIT(pipe)) == 0)
> > return;
> >
> > - crtc_state->bigjoiner = true;
> > crtc_state->bigjoiner_pipes =
> > BIT(get_bigjoiner_master_pipe(pipe, master_pipes, slave_pipes))
> > |
> > get_bigjoiner_slave_pipes(pipe, master_pipes, slave_pipes);
>
> Although not part of this patch, do we need to check if
> get_bigjoiner_master_pipe() does not give PIPE_INVALID?
>
> Perhaps in a case where master_pipe is read as 0 but some garbage for
> slave_pipes during readout?
>
> Should there be a check for INVALID_PIPE, before feeding into BIT() macro?
I think if we want to do more thourough validation against totally bogus
hardware programming then we should just do it once at the start.
enabled_bigjoiner_pipes() does have something, but it's only good for
the two joined pipes cases. Also it just warns and doesn't do anything
more than that atm. The simple option might be to make it just zero out
the masks entirely if they look totally bogus. The readout would then
be skipped for all slave pipes.
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Don't pollute crtc_state->mode_blob with error pointers
On Wed, Feb 09, 2022 at 11:19:27AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make sure we don't assign an error pointer to crtc_state->mode_blob
> as that will break all kinds of places that assume either NULL or a
> valid pointer (eg. drm_property_blob_put()).
>
> Reported-by: fuyufan
> Signed-off-by: Ville Syrjälä
Slapped on a cc:stable just in case this can actually happen
in the wild, and pushed to drm-misc-fixes with Maxime's irc ack
(thanks).
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9781722519c3..54d62fdb4ef9 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -76,15 +76,17 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
> *state,
> state->mode_blob = NULL;
>
> if (mode) {
> + struct drm_property_blob *blob;
> +
> drm_mode_convert_to_umode(&umode, mode);
> - state->mode_blob =
> - drm_property_create_blob(state->crtc->dev,
> - sizeof(umode),
> - &umode);
> - if (IS_ERR(state->mode_blob))
> - return PTR_ERR(state->mode_blob);
> + blob = drm_property_create_blob(crtc->dev,
> + sizeof(umode), &umode);
> + if (IS_ERR(blob))
> + return PTR_ERR(blob);
>
> drm_mode_copy(&state->mode, mode);
> +
> + state->mode_blob = blob;
> state->enable = true;
> drm_dbg_atomic(crtc->dev,
> "Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
> --
> 2.34.1
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915: Define MCH registers relative to MCHBAR_MIRROR_BASE
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Define MCH registers relative
to MCHBAR_MIRROR_BASE
URL : https://patchwork.freedesktop.org/series/100153/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11230_full -> Patchwork_22278_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22278_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22278_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
--
Missing(1): shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22278_full:
### IGT changes ###
Possible regressions
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-glk6/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@drm_import_export@import-close-race-prime:
- {shard-rkl}:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/igt@drm_import_exp...@import-close-race-prime.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-rkl-5/igt@drm_import_exp...@import-close-race-prime.html
* igt@gem_caching@read-writes:
- {shard-rkl}:NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-rkl-5/igt@gem_cach...@read-writes.html
* igt@gem_mmap_offset@open-flood:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][6] +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-rkl-5/igt@gem_mmap_off...@open-flood.html
* igt@i915_selftest@live@gt_timelines:
- {shard-rkl}:[PASS][7] -> ([PASS][8], [INCOMPLETE][9])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/igt@i915_selftest@live@gt_timelines.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-rkl-4/igt@i915_selftest@live@gt_timelines.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-rkl-5/igt@i915_selftest@live@gt_timelines.html
Known issues
Here are the changes found in Patchwork_22278_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- {shard-rkl}:([PASS][10], [PASS][11], [PASS][12], [FAIL][13],
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) ->
([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31],
[PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37],
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43],
[PASS][44], [PASS][45])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-rkl-1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-rkl-6/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22278/shard-r
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Eliminate bigjoiner boolean
On 2/16/2022 4:34 PM, Ville Syrjälä wrote:
On Wed, Feb 16, 2022 at 04:27:49PM +0530, Nautiyal, Ankit K wrote:
On 2/16/2022 12:02 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Since we now have the bigjoiner_pipes bitmask the boolean
is redundant. Get rid of it.
Also, populating bigjoiner_pipes already during
encoder->compute_config() allows us to use it much earlier
during the state calculation as well. The initial aim is
to use it in intel_crtc_compute_config().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cursor.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 50 ---
.../drm/i915/display/intel_display_debugfs.c | 2 +-
.../drm/i915/display/intel_display_types.h| 3 --
drivers/gpu/drm/i915/display/intel_dp.c | 13 ++---
drivers/gpu/drm/i915/display/intel_vdsc.c | 8 +--
.../drm/i915/display/skl_universal_plane.c| 2 +-
7 files changed, 36 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index 1f448f4e9aaf..da6cf0515164 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -640,7 +640,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
* FIXME bigjoiner fastpath would be good
*/
if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
- crtc_state->update_pipe || crtc_state->bigjoiner)
+ crtc_state->update_pipe || crtc_state->bigjoiner_pipes)
goto slow;
/*
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 47b5d8cc16fd..192474163edb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1926,7 +1926,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
if (drm_WARN_ON(&dev_priv->drm, crtc->active))
return;
- if (!new_crtc_state->bigjoiner) {
+ if (!new_crtc_state->bigjoiner_pipes) {
intel_encoders_pre_pll_enable(state, crtc);
if (new_crtc_state->shared_dpll)
@@ -2727,7 +2727,7 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
*crtc_state,
struct drm_display_mode *mode)
{
- if (!crtc_state->bigjoiner)
+ if (!crtc_state->bigjoiner_pipes)
return;
mode->crtc_clock /= 2;
@@ -2811,7 +2811,7 @@ static void intel_bigjoiner_compute_pipe_src(struct
intel_crtc_state *crtc_state
{
int width, height;
- if (!crtc_state->bigjoiner)
+ if (!crtc_state->bigjoiner_pipes)
return;
width = drm_rect_width(&crtc_state->pipe_src);
@@ -4218,7 +4218,6 @@ static void intel_bigjoiner_get_config(struct
intel_crtc_state *crtc_state)
if (((master_pipes | slave_pipes) & BIT(pipe)) == 0)
return;
- crtc_state->bigjoiner = true;
crtc_state->bigjoiner_pipes =
BIT(get_bigjoiner_master_pipe(pipe, master_pipes, slave_pipes))
|
get_bigjoiner_slave_pipes(pipe, master_pipes, slave_pipes);
Although not part of this patch, do we need to check if
get_bigjoiner_master_pipe() does not give PIPE_INVALID?
Perhaps in a case where master_pipe is read as 0 but some garbage for
slave_pipes during readout?
Should there be a check for INVALID_PIPE, before feeding into BIT() macro?
I think if we want to do more thourough validation against totally bogus
hardware programming then we should just do it once at the start.
enabled_bigjoiner_pipes() does have something, but it's only good for
the two joined pipes cases. Also it just warns and doesn't do anything
more than that atm. The simple option might be to make it just zero out
the masks entirely if they look totally bogus. The readout would then
be skipped for all slave pipes.
Yes you are right, enabled_bigjoiner_pipes does have a check in the end
and that will prevent bogus value to
a certain extent. Given case would not occur, atleast for two joined
pipes case.
Anyways, the patch seems to be straight forward and looks good to me.
Reviewed-by: Ankit Nautiyal
Re: [Intel-gfx] [PATCH 09/12] drm/i915: Start tracking PIPESRC as a drm_rect
On Tue, Feb 15, 2022 at 08:32:05PM +0200, Ville Syrjala wrote: > @@ -2788,8 +2788,9 @@ static void intel_crtc_readout_derived_state(struct > intel_crtc_state *crtc_state > /* Populate the "user" mode with full numbers */ > drm_mode_copy(mode, pipe_mode); > intel_mode_from_crtc_timings(mode, mode); > - mode->hdisplay = crtc_state->pipe_src_w << crtc_state->bigjoiner; > - mode->vdisplay = crtc_state->pipe_src_h; > + mode->hdisplay = drm_rect_width(&crtc_state->pipe_src) * > + (hweight8(crtc_state->bigjoiner_pipes) ?: 1); That hweight() stuff was supposed to be in one of the later patches btw. Looks like I accidentally squashed it here when splitting/reordering stuff. > + mode->vdisplay = drm_rect_height(&crtc_state->pipe_src); > > /* Derive per-pipe timings in case bigjoiner is used */ > intel_bigjoiner_adjust_timings(crtc_state, pipe_mode); -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915/guc: Initialize GuC submission locks and queues early
On 15/02/2022 16:39, Ceraolo Spurio, Daniele wrote:
On 2/15/2022 1:09 AM, Tvrtko Ursulin wrote:
On 15/02/2022 01:11, Daniele Ceraolo Spurio wrote:
Move initialization of submission-related spinlock, lists and workers to
init_early. This fixes an issue where if the GuC init fails we might
still try to get the lock in the context cleanup code. Note that it is
What's the worst case impact on non-debug builds aka is Fixes: required?
There is no lock contention in this scenario and nothing is done within
the locked section (because submission is not initialized and all
contexts are marked as invalid), so no problems from the fact that the
lock doesn't work. Is that enough to avoid a fixes tag?
If the "lock doesn't work" is benign due no chance of touching
uninitialised memory and then deadlocking then it's good. I just
couldn't read that part from the commit message and did not have time to
go dig into the code.
Regards,
Tvrtko
Daniele
Regards,
Tvrtko
safe to call the GuC context cleanup code even if the init failed
because all contexts are initialized with an invalid GuC ID, which will
cause the GuC side of the cleanup to be skipped, so it is easier to just
make sure the variables are initialized than to special case the cleanup
to handle the case when they're not.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4932
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Brost
Cc: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 27 ++-
1 file changed, 14 insertions(+), 13 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 b3a429a92c0da..2160da2c83cbf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1818,24 +1818,11 @@ int intel_guc_submission_init(struct
intel_guc *guc)
*/
GEM_BUG_ON(!guc->lrc_desc_pool);
- xa_init_flags(&guc->context_lookup, XA_FLAGS_LOCK_IRQ);
-
- spin_lock_init(&guc->submission_state.lock);
- INIT_LIST_HEAD(&guc->submission_state.guc_id_list);
- ida_init(&guc->submission_state.guc_ids);
- INIT_LIST_HEAD(&guc->submission_state.destroyed_contexts);
- INIT_WORK(&guc->submission_state.destroyed_worker,
- destroyed_worker_func);
- INIT_WORK(&guc->submission_state.reset_fail_worker,
- reset_fail_worker_func);
-
guc->submission_state.guc_ids_bitmap =
bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
if (!guc->submission_state.guc_ids_bitmap)
return -ENOMEM;
- spin_lock_init(&guc->timestamp.lock);
- INIT_DELAYED_WORK(&guc->timestamp.work, guc_timestamp_ping);
guc->timestamp.ping_delay = (POLL_TIME_CLKS /
gt->clock_frequency + 1) * HZ;
guc->timestamp.shift = gpm_timestamp_shift(gt);
@@ -3831,6 +3818,20 @@ static bool __guc_submission_selected(struct
intel_guc *guc)
void intel_guc_submission_init_early(struct intel_guc *guc)
{
+ xa_init_flags(&guc->context_lookup, XA_FLAGS_LOCK_IRQ);
+
+ spin_lock_init(&guc->submission_state.lock);
+ INIT_LIST_HEAD(&guc->submission_state.guc_id_list);
+ ida_init(&guc->submission_state.guc_ids);
+ INIT_LIST_HEAD(&guc->submission_state.destroyed_contexts);
+ INIT_WORK(&guc->submission_state.destroyed_worker,
+ destroyed_worker_func);
+ INIT_WORK(&guc->submission_state.reset_fail_worker,
+ reset_fail_worker_func);
+
+ spin_lock_init(&guc->timestamp.lock);
+ INIT_DELAYED_WORK(&guc->timestamp.work, guc_timestamp_ping);
+
guc->submission_state.num_guc_ids = GUC_MAX_LRC_DESCRIPTORS;
guc->submission_supported = __guc_submission_supported(guc);
guc->submission_selected = __guc_submission_selected(guc);
Re: [Intel-gfx] [PATCH v8 1/3] gpu: drm: separate panel orientation property creating and value setting
On Tue, 15 Feb 2022 at 16:37, Simon Ser wrote: > > On Tuesday, February 15th, 2022 at 15:38, Emil Velikov > wrote: > > > On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote: > > > > > > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov > > > wrote: > > > > > > > Greetings everyone, > > > > > > > > Padron for joining in so late o/ > > > > > > > > On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote: > > > > > > > > > > drm_dev_register() sets connector->registration_state to > > > > > DRM_CONNECTOR_REGISTERED and dev->registered to true. If > > > > > drm_connector_set_panel_orientation() is first called after > > > > > drm_dev_register(), it will fail several checks and results in > > > > > following > > > > > warning. > > > > > > > > > > Add a function to create panel orientation property and set default > > > > > value > > > > > to UNKNOWN, so drivers can call this function to init the property > > > > > earlier > > > > > , and let the panel set the real value later. > > > > > > > > > > > > > The warning illustrates a genuine race condition, where userspace will > > > > read the old/invalid property value/state. So this patch masks away > > > > the WARNING without addressing the actual issue. > > > > Instead can we fix the respective drivers, so that no properties are > > > > created after drm_dev_register()? > > > > > > > > Longer version: > > > > As we look into drm_dev_register() it's in charge of creating the > > > > dev/sysfs nodes (et al). Note that connectors cannot disappear at > > > > runtime. > > > > For panel orientation, we are creating an immutable connector > > > > properly, meaning that as soon as drm_dev_register() is called we must > > > > ensure that the property is available (if applicable) and set to the > > > > correct value. > > > > > > Unfortunately we can't quite do this. To apply the panel orientation > > > quirks we > > > need to grab the EDID of the eDP connector, and this happened too late in > > > my > > > testing. > > > > > > What we can do is create the prop early during module load, and update it > > > when > > > we read the EDID (at the place where we create it right now). User-space > > > will > > > receive a hotplug event after the EDID is read, so will be able to pick > > > up the > > > new value if any. > > > > Didn't quite get that, are you saying that a GETPROPERTY for the EDID, > > the ioctl blocks or that we get an empty EDID? > > I'm not referring to GETPROPERTY, I'm referring to the driver getting the EDID > from the sink (here, the eDP panel). In my experimentations with amdgpu I > noticed that the driver module load finished before the EDID was available to > the driver. Maybe other drivers behave differently and probe connectors when > loaded, not sure. > I see thanks. > > The EDID hotplug even thing is neat - sounds like it also signals on > > panel orientation, correct? > > On such an event, which properties userspace should be re-fetching - > > everything or guess randomly? > > > > Looking through the documentation, I cannot see a clear answer :-\ > > User-space should re-fetch *all* properties. In practice some user-space may > only be fetching some properties, but that should get fixed in user-space. > > Also the kernel can indicate that only a single connector changed via the > "CONNECTOR" uevent prop, or even a single connector property via "PROPERTY". > See [1] for a user-space implementation. But all of this is purely an optional > optimization. Re-fetching all properties is a bit slower (especially if some > drmModeGetConnector calls force-probe connectors) but works perfectly fine. > Looking at KDE/kwin (the one I'm running) - doesn't seem like it handles any of the three "HOTPLUG", "PROPERTY" or "CONNECTOR" uevents :-\ Skimming through GNOME/mutter - it handles "HOTPLUG", but not the optional ones. Guess we're in the clear wrt potential races, even though the documentation on the topic is lacklustre. > It would be nice to document, if you have the time feel free to send a patch > and CC danvet, pq and me. > Doubt I will have the time in the upcoming weeks, but I'll add it to my ever-growing TODO list :-P Thanks Emil
Re: [Intel-gfx] [PATCH v7 1/5] drm/i915/gsc: add gsc as a mei auxiliary device
On 15/02/2022 15:22, Usyskin, Alexander wrote:
+{
+ irq_set_chip_and_handler_name(irq, &gsc_irq_chip,
+ handle_simple_irq, "gsc_irq_handler");
+
+ return irq_set_chip_data(irq, dev_priv);
I am not familiar with this interrupt scheme - does dev_priv get used at
all by handle_simple_irq, or anyone, after being set here?
What about this? Is dev_priv required or you could pass in NULL just as
well?
+}
+
+struct intel_gsc_def {
+ const char *name;
+ const unsigned long bar;
Unusual, why const out of curiosity? And is it "bar" or "base" would be
more accurate?
Some leftover, thanks for spotting this!
It is a base of bar. I prefer bar name here. But not really matter.
Is it?
+ adev->bar.start = def->bar + pdev->resource[0].start;
Looks like offset on top of BAR, no?
+{
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
+ struct mei_aux_device *adev;
+ struct auxiliary_device *aux_dev;
+ const struct intel_gsc_def *def;
+ int ret;
+
+ intf->irq = -1;
+ intf->id = intf_id;
+
+ if (intf_id == 0 && !HAS_HECI_PXP(dev_priv))
+ return;
Isn't inf_id == 0 always a bug with this patch, regardless of
HAS_HECI_PXP, since the support is incomplete in this patch? If so I'd
be more comfortable with a plain drm_WARN_ON_ONCE(intf_id == 0).
There will be patches for other cards that have pxp as soon as this is reviewed.
It is better to have infra prepared for two heads.
My point is things are half-prepared since you don't have the id 0 in
the array, regardless of the HAS_HECI_PXP. Yes it can't be true now, but
if you add a patch which enables it to be true, you have to modify the
array at the same time or risk a broken patch in the middle.
I don't see the point of the condition making it sound like there are
two criteria to enter below, while in fact there is only one in current
code, and that it that it must not be entered because array is incomplete!
+
+ if (!HAS_HECI_GSC(gt->i915))
+ return;
Likewise?
+
+ if (gt->gsc.intf[intf_id].irq <= 0) {
+ DRM_ERROR_RATELIMITED("error handling GSC irq: irq not
set");
Like this, but use logging functions which say which device please.
drm_err_ratelimited fits here?
AFAICT it would be a programming bug and not something that can happen
at runtime hence drm_warn_on_once sounds correct for both.
}
@@ -182,6 +185,8 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
/* Disable RCS, BCS, VCS and VECS class engines. */
intel_uncore_write(uncore, GEN11_RENDER_COPY_INTR_ENABLE,
0);
intel_uncore_write(uncore, GEN11_VCS_VECS_INTR_ENABLE,0);
+ if (HAS_HECI_GSC(gt->i915))
+ intel_uncore_write(uncore,
GEN11_GUNIT_CSME_INTR_ENABLE, 0);
/* Restore masks irqs on RCS, BCS, VCS and VECS engines. */
intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~0);
@@ -195,6 +200,8 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK,
~0);
if (HAS_ENGINE(gt, VECS2) || HAS_ENGINE(gt, VECS3))
intel_uncore_write(uncore,
GEN12_VECS2_VECS3_INTR_MASK, ~0);
+ if (HAS_HECI_GSC(gt->i915))
+ intel_uncore_write(uncore,
GEN11_GUNIT_CSME_INTR_MASK, ~0);
intel_uncore_write(uncore,
GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
intel_uncore_write(uncore,
GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
@@ -209,6 +216,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
{
struct intel_uncore *uncore = gt->uncore;
u32 irqs = GT_RENDER_USER_INTERRUPT;
+ const u32 gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
Why enable the one which is not supported by the patch? No harm doing it?
No harm and the next patch will be soon, this patch unfortunately is long
overdue.
Just feels a bit lazy. You are adding two feature test macros to
prepare, so why not use them.
Regards,
Tvrtko
[Intel-gfx] ✗ Fi.CI.IGT: failure for iommu/vt-d: Add RPLS to quirk list to skip TE disabling
== Series Details ==
Series: iommu/vt-d: Add RPLS to quirk list to skip TE disabling
URL : https://patchwork.freedesktop.org/series/100165/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11230_full -> Patchwork_22280_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22280_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22280_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
--
Missing(1): shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22280_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- shard-iclb: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-iclb3/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-iclb7/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- shard-glk: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-glk8/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_schedule@wide@vecs0:
- {shard-rkl}:[PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/igt@gem_exec_schedule@w...@vecs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-5/igt@gem_exec_schedule@w...@vecs0.html
* igt@gem_mmap_offset@open-flood:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-5/igt@gem_mmap_off...@open-flood.html
Known issues
Here are the changes found in Patchwork_22280_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- {shard-rkl}:([PASS][8], [PASS][9], [PASS][10], [FAIL][11],
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17],
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23]) ->
([PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35],
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-1/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-2/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22280/shard-rkl-4/boot.html
[31]:
https://intel-gfx-ci.01.org/t
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Use bigjoiner_pipes more
LGTM.
Reviewed-by: Ankit Nautiyal
On 2/16/2022 12:02 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Replace the hardcoded 2 pipe assumptions when we're massaging
pipe_mode and the pipe_src rect to be suitable for bigjoiner.
Instead we can just count the number of pipes in the bitmask.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 23 +++-
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 192474163edb..0690470eab97 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2727,16 +2727,18 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
*crtc_state,
struct drm_display_mode *mode)
{
- if (!crtc_state->bigjoiner_pipes)
+ int num_pipes = hweight8(crtc_state->bigjoiner_pipes);
+
+ if (num_pipes < 2)
return;
- mode->crtc_clock /= 2;
- mode->crtc_hdisplay /= 2;
- mode->crtc_hblank_start /= 2;
- mode->crtc_hblank_end /= 2;
- mode->crtc_hsync_start /= 2;
- mode->crtc_hsync_end /= 2;
- mode->crtc_htotal /= 2;
+ mode->crtc_clock /= num_pipes;
+ mode->crtc_hdisplay /= num_pipes;
+ mode->crtc_hblank_start /= num_pipes;
+ mode->crtc_hblank_end /= num_pipes;
+ mode->crtc_hsync_start /= num_pipes;
+ mode->crtc_hsync_end /= num_pipes;
+ mode->crtc_htotal /= num_pipes;
}
static void intel_splitter_adjust_timings(const struct intel_crtc_state *crtc_state,
@@ -2809,16 +2811,17 @@ static void intel_encoder_get_config(struct
intel_encoder *encoder,
static void intel_bigjoiner_compute_pipe_src(struct intel_crtc_state *crtc_state)
{
+ int num_pipes = hweight8(crtc_state->bigjoiner_pipes);
int width, height;
- if (!crtc_state->bigjoiner_pipes)
+ if (num_pipes < 2)
return;
width = drm_rect_width(&crtc_state->pipe_src);
height = drm_rect_height(&crtc_state->pipe_src);
drm_rect_init(&crtc_state->pipe_src, 0, 0,
- width / 2, height);
+ width / num_pipes, height);
}
static int intel_crtc_compute_pipe_src(struct intel_crtc_state *crtc_state)
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Use bigjoiner_pipes more
On Tue, Feb 15, 2022 at 08:32:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hardcoded 2 pipe assumptions when we're massaging
> pipe_mode and the pipe_src rect to be suitable for bigjoiner.
> Instead we can just count the number of pipes in the bitmask.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 23 +++-
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 192474163edb..0690470eab97 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2727,16 +2727,18 @@ static void intel_crtc_compute_pixel_rate(struct
> intel_crtc_state *crtc_state)
> static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> struct drm_display_mode *mode)
> {
> - if (!crtc_state->bigjoiner_pipes)
> + int num_pipes = hweight8(crtc_state->bigjoiner_pipes);
Also just occurred to me that we might want to abstract that a bit
more since it gets repeated in several places. Could be a followup
too I suppose.
> +
> + if (num_pipes < 2)
> return;
>
> - mode->crtc_clock /= 2;
> - mode->crtc_hdisplay /= 2;
> - mode->crtc_hblank_start /= 2;
> - mode->crtc_hblank_end /= 2;
> - mode->crtc_hsync_start /= 2;
> - mode->crtc_hsync_end /= 2;
> - mode->crtc_htotal /= 2;
> + mode->crtc_clock /= num_pipes;
> + mode->crtc_hdisplay /= num_pipes;
> + mode->crtc_hblank_start /= num_pipes;
> + mode->crtc_hblank_end /= num_pipes;
> + mode->crtc_hsync_start /= num_pipes;
> + mode->crtc_hsync_end /= num_pipes;
> + mode->crtc_htotal /= num_pipes;
> }
>
> static void intel_splitter_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> @@ -2809,16 +2811,17 @@ static void intel_encoder_get_config(struct
> intel_encoder *encoder,
>
> static void intel_bigjoiner_compute_pipe_src(struct intel_crtc_state
> *crtc_state)
> {
> + int num_pipes = hweight8(crtc_state->bigjoiner_pipes);
> int width, height;
>
> - if (!crtc_state->bigjoiner_pipes)
> + if (num_pipes < 2)
> return;
>
> width = drm_rect_width(&crtc_state->pipe_src);
> height = drm_rect_height(&crtc_state->pipe_src);
>
> drm_rect_init(&crtc_state->pipe_src, 0, 0,
> - width / 2, height);
> + width / num_pipes, height);
> }
>
> static int intel_crtc_compute_pipe_src(struct intel_crtc_state *crtc_state)
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Introduce intel_arm_planes_on_crtc()
On Wed, Feb 16, 2022 at 11:38:44AM +0200, Jani Nikula wrote:
> On Fri, 11 Feb 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > No reason the high level intel_update_crtc() needs to know
> > that there is something magical about the commit order of
> > planes between different platforms. So let's hide that
> > detail even better.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 19 +++
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 6 ++
> > drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> > 3 files changed, 18 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 3355eb637eac..bba2f105b7dd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -716,8 +716,8 @@ void intel_update_planes_on_crtc(struct
> > intel_atomic_state *state,
> > }
> > }
> >
> > -void skl_arm_planes_on_crtc(struct intel_atomic_state *state,
> > - struct intel_crtc *crtc)
> > +static void skl_arm_planes_on_crtc(struct intel_atomic_state *state,
> > + struct intel_crtc *crtc)
> > {
> > struct intel_crtc_state *old_crtc_state =
> > intel_atomic_get_old_crtc_state(state, crtc);
> > @@ -751,8 +751,8 @@ void skl_arm_planes_on_crtc(struct intel_atomic_state
> > *state,
> > }
> > }
> >
> > -void i9xx_arm_planes_on_crtc(struct intel_atomic_state *state,
> > -struct intel_crtc *crtc)
> > +static void i9xx_arm_planes_on_crtc(struct intel_atomic_state *state,
> > + struct intel_crtc *crtc)
> > {
> > struct intel_crtc_state *new_crtc_state =
> > intel_atomic_get_new_crtc_state(state, crtc);
> > @@ -777,6 +777,17 @@ void i9xx_arm_planes_on_crtc(struct intel_atomic_state
> > *state,
> > }
> > }
> >
> > +void intel_arm_planes_on_crtc(struct intel_atomic_state *state,
> > + struct intel_crtc *crtc)
> > +{
>
> I don't much like the intel_arm_ prefix here. I'd go for intel_plane_
> something or other.
intel_plane_ is rather bad since this operates on multiple planes.
Though I'm not super happy with the _arm_ vs. _update_ thing we have
going on now. The plane hooks I made .update_noarm() and .update_arm()
(which certainly has a few bad puns in it) so should perhaps just
try to follow a similar naming convention for the high level stuff.
I guess I'd prefer intel_crtc_ as the prefix actually since thats
what we pass in anyway.
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Remove nop bigjoiner state copy
On 2/16/2022 12:01 AM, Ville Syrjala wrote: From: Ville Syrjälä We just copied over the whole master crtc state, including cpu_transcoder+has_audio. No need to copy those again. Also get rid of the unhelpful comment. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 622903847551..49ca13abd108 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -5779,12 +5779,9 @@ copy_bigjoiner_crtc_state_modeset(struct intel_atomic_state *state, copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc); - /* Some fixups */ slave_crtc_state->uapi.mode_changed = master_crtc_state->uapi.mode_changed; slave_crtc_state->uapi.connectors_changed = master_crtc_state->uapi.connectors_changed; slave_crtc_state->uapi.active_changed = master_crtc_state->uapi.active_changed; - slave_crtc_state->cpu_transcoder = master_crtc_state->cpu_transcoder; - slave_crtc_state->has_audio = master_crtc_state->has_audio; Makes sense, these two are only set, uapi was preserved from older slave state, so only the relevant bits need to be copied from master here. Reviewed-by: Ankit Nautiyal return 0; }
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Introduce intel_arm_planes_on_crtc()
On Wed, 16 Feb 2022, Ville Syrjälä wrote:
> On Wed, Feb 16, 2022 at 11:38:44AM +0200, Jani Nikula wrote:
>> On Fri, 11 Feb 2022, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > No reason the high level intel_update_crtc() needs to know
>> > that there is something magical about the commit order of
>> > planes between different platforms. So let's hide that
>> > detail even better.
>> >
>> > Signed-off-by: Ville Syrjälä
>> > ---
>> > .../gpu/drm/i915/display/intel_atomic_plane.c | 19 +++
>> > .../gpu/drm/i915/display/intel_atomic_plane.h | 6 ++
>> > drivers/gpu/drm/i915/display/intel_display.c | 6 +-
>> > 3 files changed, 18 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>> > index 3355eb637eac..bba2f105b7dd 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>> > @@ -716,8 +716,8 @@ void intel_update_planes_on_crtc(struct
>> > intel_atomic_state *state,
>> >}
>> > }
>> >
>> > -void skl_arm_planes_on_crtc(struct intel_atomic_state *state,
>> > - struct intel_crtc *crtc)
>> > +static void skl_arm_planes_on_crtc(struct intel_atomic_state *state,
>> > + struct intel_crtc *crtc)
>> > {
>> >struct intel_crtc_state *old_crtc_state =
>> >intel_atomic_get_old_crtc_state(state, crtc);
>> > @@ -751,8 +751,8 @@ void skl_arm_planes_on_crtc(struct intel_atomic_state
>> > *state,
>> >}
>> > }
>> >
>> > -void i9xx_arm_planes_on_crtc(struct intel_atomic_state *state,
>> > - struct intel_crtc *crtc)
>> > +static void i9xx_arm_planes_on_crtc(struct intel_atomic_state *state,
>> > + struct intel_crtc *crtc)
>> > {
>> >struct intel_crtc_state *new_crtc_state =
>> >intel_atomic_get_new_crtc_state(state, crtc);
>> > @@ -777,6 +777,17 @@ void i9xx_arm_planes_on_crtc(struct
>> > intel_atomic_state *state,
>> >}
>> > }
>> >
>> > +void intel_arm_planes_on_crtc(struct intel_atomic_state *state,
>> > +struct intel_crtc *crtc)
>> > +{
>>
>> I don't much like the intel_arm_ prefix here. I'd go for intel_plane_
>> something or other.
>
> intel_plane_ is rather bad since this operates on multiple planes.
> Though I'm not super happy with the _arm_ vs. _update_ thing we have
> going on now. The plane hooks I made .update_noarm() and .update_arm()
> (which certainly has a few bad puns in it) so should perhaps just
> try to follow a similar naming convention for the high level stuff.
>
> I guess I'd prefer intel_crtc_ as the prefix actually since thats
> what we pass in anyway.
We can bikeshed this later, I think the patch is net positive as-is.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH v2] drm/i915/display/tgl+: Implement new PLL programming step
A new programming step was added to combo and TC PLL sequences.
If override_AFC_startup is set in VBT, driver should overwrite
AFC_startup value to 0x0 or 0x7 in PLL's div0 register.
The current understating is that only TGL needs this and all other
display 12 and newer platforms will have a older VBT or a newer VBT
with override_AFC_startup set to 0 but in any case there is a
drm_warn_on_once() to let us know if this is not true.
v2:
- specification updated, now AFC can be override to 0x0 or 0x7
- not using a union for div0 (Imre)
- following previous wrong vbt naming: bits instead of bytes (Imre)
BSpec: 49204
BSpec: 20122
BSpec: 49968
BSpec: 71360
Cc: Imre Deak
Cc: Jani Nikula
Reviewed-by: Imre Deak # v1
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 6 +++
drivers/gpu/drm/i915/display/intel_display.c | 1 +
.../drm/i915/display/intel_display_debugfs.c | 1 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 44 +--
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 3 ++
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 8
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 12 +
8 files changed, 65 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index aec0efd5350ef..40b5e7ed12c20 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -596,6 +596,12 @@ parse_general_features(struct drm_i915_private *i915,
} else {
i915->vbt.orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
}
+
+ if (bdb->version >= 249 && general->afc_startup_config) {
+ i915->vbt.override_afc_startup = true;
+ i915->vbt.override_afc_startup_val =
general->afc_startup_config == 0x1 ? 0x0 : 0x7;
+ }
+
drm_dbg_kms(&i915->drm,
"BDB_GENERAL_FEATURES int_tv_support %d int_crt_support %d
lvds_use_ssc %d lvds_ssc_freq %d display_clock_mode %d fdi_rx_polarity_inverted
%d\n",
i915->vbt.int_tv_support,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6229038475513..9e663692b0f00 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6502,6 +6502,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr1);
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr2);
PIPE_CONF_CHECK_X(dpll_hw_state.cfgcr0);
+ PIPE_CONF_CHECK_X(dpll_hw_state.div0);
PIPE_CONF_CHECK_X(dpll_hw_state.ebb0);
PIPE_CONF_CHECK_X(dpll_hw_state.ebb4);
PIPE_CONF_CHECK_X(dpll_hw_state.pll0);
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 1a202a5c39a53..56b86781a7b16 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1014,6 +1014,7 @@ static int i915_shared_dplls_info(struct seq_file *m,
void *unused)
seq_printf(m, " wrpll: 0x%08x\n", pll->state.hw_state.wrpll);
seq_printf(m, " cfgcr0: 0x%08x\n", pll->state.hw_state.cfgcr0);
seq_printf(m, " cfgcr1: 0x%08x\n", pll->state.hw_state.cfgcr1);
+ seq_printf(m, " div0:0x%08x\n", pll->state.hw_state.div0);
seq_printf(m, " mg_refclkin_ctl:0x%08x\n",
pll->state.hw_state.mg_refclkin_ctl);
seq_printf(m, " mg_clktop2_coreclkctl1: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 6723c3de5a80c..569903d47aea5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -2748,6 +2748,9 @@ static void icl_calc_dpll_state(struct drm_i915_private
*i915,
pll_state->cfgcr1 |= TGL_DPLL_CFGCR1_CFSELOVRD_NORMAL_XTAL;
else
pll_state->cfgcr1 |= DPLL_CFGCR1_CENTRAL_FREQ_8400;
+
+ if (i915->vbt.override_afc_startup)
+ pll_state->div0 =
TGL_DPLL0_DIV0_AFC_STARTUP(i915->vbt.override_afc_startup_val);
}
static bool icl_mg_pll_find_divisors(int clock_khz, bool is_dp, bool use_ssc,
@@ -2949,6 +2952,11 @@ static bool icl_calc_mg_pll_state(struct
intel_crtc_state *crtc_state,
DKL_PLL_DIV0_PROP_COEFF(prop_coeff) |
DKL_PLL_DIV0_FBPREDIV(m1div) |
DKL_PLL_DIV0_FBDIV_INT(m2div_int);
+ if (dev_priv->vbt.override_afc_startup) {
+ u8 val = dev_priv->vbt.override_afc_startup_val;
+
+
Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Implement Wa_16013835468
On Tue, 2022-02-15 at 15:47 +0200, Lisovskiy, Stanislav wrote:
> On Thu, Feb 10, 2022 at 10:52:23AM -0800, José Roberto de Souza wrote:
> > PSR2 workaround required when mode has delayed vblank.
> >
> > BSpec: 52890
> > BSpec: 49421
> > Cc: Jouni Högander
> > Signed-off-by: José Roberto de Souza
>
>
> I think we better implement it in a more generic way.
> BSpec 71580 formulates this workaround more precisely:
>
> "
> If any low power watermark is disabled because the package C state
> has too much latency for the size of Vblank and PSR1 or PSR2 is enabled,
> set the register bit for this pipe (listing below) to 1 to disable a
> PSR optimization to override to the maximum watermark.
> Clear the bit if the size of Vblank does not require low power watermarks to
> be disabled
> or PSR* is disabled."
This is a different workaround than the one implemented in this patch.
The programming bits are the same but they have different "triggers" checks.
>
>
> Pipe A 0x46430 bit 23
>
> Pipe B 0x46430 bit 24
>
> Pipe C 0x46430 bit 25
>
> Pipe D 0x46430 bit 31
>
>
> TRANS_SET_CONTEXT_LATENCY is used to delay the vblank"
>
>
> Almost we must ensure that one:
>
> Vblank time >= MAX(framestart delay + package C state latency + watermark 0
> time + pipe scaler pre-fill time + DSC pre-fill time,
>PSR2 vblank time, SDP vblank time)
>
> Line time >= PSR2 line time
>
> I'm currently working on the latter one. I have suggestion that one I finish
> with calculations required for this formula, I can provide some api for this
> patch in order to check if PSR can be enabled and workaround has to be
> applied.
>
> Stan
>
>
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 40 ++--
> > drivers/gpu/drm/i915/i915_reg.h | 13 +---
> > 2 files changed, 46 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 72bd8d3261e0c..2e0b092f4b6be 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1063,7 +1063,23 @@ static void intel_psr_activate(struct intel_dp
> > *intel_dp)
> > intel_dp->psr.active = true;
> > }
> >
> > -static void intel_psr_enable_source(struct intel_dp *intel_dp)
> > +static u32 wa_16013835468_bit_get(struct intel_dp *intel_dp)
> > +{
> > + switch (intel_dp->psr.pipe) {
> > + case PIPE_A:
> > + return LATENCY_REPORTING_REMOVED_PIPE_A;
> > + case PIPE_B:
> > + return LATENCY_REPORTING_REMOVED_PIPE_B;
> > + case PIPE_C:
> > + return LATENCY_REPORTING_REMOVED_PIPE_C;
> > + default:
> > + MISSING_CASE(intel_dp->psr.pipe);
> > + return 0;
> > + }
> > +}
> > +
> > +static void intel_psr_enable_source(struct intel_dp *intel_dp,
> > + const struct intel_crtc_state *crtc_state)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > @@ -1133,6 +1149,20 @@ static void intel_psr_enable_source(struct intel_dp
> > *intel_dp)
> > if (IS_ALDERLAKE_P(dev_priv))
> > intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
> > CLKGATE_DIS_MISC_DMASC_GATING_DIS);
> > +
> > + /* Wa_16013835468:tgl[b0+], dg1 */
> > + if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
> > + IS_DG1(dev_priv)) {
> > + u16 vtotal, vblank;
> > +
> > + vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
> > +crtc_state->uapi.adjusted_mode.crtc_vdisplay;
> > + vblank = crtc_state->uapi.adjusted_mode.crtc_vblank_end
> > -
> > +
> > crtc_state->uapi.adjusted_mode.crtc_vblank_start;
> > + if (vblank > vtotal)
> > + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> > +wa_16013835468_bit_get(intel_dp));
> > + }
> > }
> > }
> >
> > @@ -1198,7 +1228,7 @@ static void intel_psr_enable_locked(struct intel_dp
> > *intel_dp,
> > intel_write_dp_vsc_sdp(encoder, crtc_state, &crtc_state->psr_vsc);
> > intel_snps_phy_update_psr_power_state(dev_priv, phy, true);
> > intel_psr_enable_sink(intel_dp);
> > - intel_psr_enable_source(intel_dp);
> > + intel_psr_enable_source(intel_dp, crtc_state);
> > intel_dp->psr.enabled = true;
> > intel_dp->psr.paused = false;
> >
> > @@ -1297,6 +1327,12 @@ static void intel_psr_disable_locked(struct intel_dp
> > *intel_dp)
> > if (IS_ALDERLAKE_P(dev_priv))
> > intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
> > CLKGATE_DIS_MISC_DMASC_GATING_DIS, 0);
> > +
> > + /* Wa_16013835468:tgl[b0+], dg1 */
> > + if (IS_TGL_DI
Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: Implement Wa_16013835468
On Tue, 2022-02-15 at 12:31 +, Hogander, Jouni wrote:
> On Thu, 2022-02-10 at 10:52 -0800, José Roberto de Souza wrote:
> > PSR2 workaround required when mode has delayed vblank.
> >
> > BSpec: 52890
> > BSpec: 49421
> > Cc: Jouni Högander
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 40
> > ++--
> > drivers/gpu/drm/i915/i915_reg.h | 13 +---
> > 2 files changed, 46 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 72bd8d3261e0c..2e0b092f4b6be 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -1063,7 +1063,23 @@ static void intel_psr_activate(struct intel_dp
> > *intel_dp)
> > intel_dp->psr.active = true;
> > }
> >
> > -static void intel_psr_enable_source(struct intel_dp *intel_dp)
> > +static u32 wa_16013835468_bit_get(struct intel_dp *intel_dp)
> > +{
> > + switch (intel_dp->psr.pipe) {
> > + case PIPE_A:
> > + return LATENCY_REPORTING_REMOVED_PIPE_A;
> > + case PIPE_B:
> > + return LATENCY_REPORTING_REMOVED_PIPE_B;
> > + case PIPE_C:
> > + return LATENCY_REPORTING_REMOVED_PIPE_C;
> > + default:
> > + MISSING_CASE(intel_dp->psr.pipe);
> > + return 0;
> > + }
> > +}
> > +
> > +static void intel_psr_enable_source(struct intel_dp *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > enum transcoder cpu_transcoder = intel_dp->psr.transcoder;
> > @@ -1133,6 +1149,20 @@ static void intel_psr_enable_source(struct
> > intel_dp *intel_dp)
> > if (IS_ALDERLAKE_P(dev_priv))
> > intel_de_rmw(dev_priv, CLKGATE_DIS_MISC, 0,
> >CLKGATE_DIS_MISC_DMASC_GATING_DIS)
> > ;
> > +
> > + /* Wa_16013835468:tgl[b0+], dg1 */
> > + if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0,
> > STEP_FOREVER) ||
> > + IS_DG1(dev_priv)) {
> > + u16 vtotal, vblank;
> > +
> > + vtotal = crtc_state-
> > > uapi.adjusted_mode.crtc_vtotal -
> > + crtc_state-
> > > uapi.adjusted_mode.crtc_vdisplay;
> > + vblank = crtc_state-
> > > uapi.adjusted_mode.crtc_vblank_end -
> > + crtc_state-
> > > uapi.adjusted_mode.crtc_vblank_start;
> > + if (vblank > vtotal)
>
> Can you please explain how this calculation indicates we are using
> "delayed vblank"?
Check the second box in Bspec 49265
>
> Otherwise patch seems to be doing what is written in WA description.
>
> > + intel_de_rmw(dev_priv,
> > GEN8_CHICKEN_DCPR_1, 0,
> > + wa_16013835468_bit_get(int
> > el_dp));
> > + }
> > }
> > }
> >
> > @@ -1198,7 +1228,7 @@ static void intel_psr_enable_locked(struct
> > intel_dp *intel_dp,
> > intel_write_dp_vsc_sdp(encoder, crtc_state, &crtc_state-
> > > psr_vsc);
> > intel_snps_phy_update_psr_power_state(dev_priv, phy, true);
> > intel_psr_enable_sink(intel_dp);
> > - intel_psr_enable_source(intel_dp);
> > + intel_psr_enable_source(intel_dp, crtc_state);
> > intel_dp->psr.enabled = true;
> > intel_dp->psr.paused = false;
> >
> > @@ -1297,6 +1327,12 @@ static void intel_psr_disable_locked(struct
> > intel_dp *intel_dp)
> > if (IS_ALDERLAKE_P(dev_priv))
> > intel_de_rmw(dev_priv, CLKGATE_DIS_MISC,
> >CLKGATE_DIS_MISC_DMASC_GATING_DIS,
> > 0);
> > +
> > + /* Wa_16013835468:tgl[b0+], dg1 */
> > + if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0,
> > STEP_FOREVER) ||
> > + IS_DG1(dev_priv))
> > + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1,
> > + wa_16013835468_bit_get(intel_dp),
> > 0);
> > }
> >
> > intel_snps_phy_update_psr_power_state(dev_priv, phy, false);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 87c92314ee269..1cd4056400b63 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6040,11 +6040,14 @@
> > #define HSW_NDE_RSTWRN_OPT _MMIO(0x46408)
> > #define RESET_PCH_HANDSHAKE_ENABLE (1 << 4)
> >
> > -#define GEN8_CHICKEN_DCPR_1 _MMIO(0x46430)
> > -#define SKL_SELECT_ALTERNATE_DC_EXIT REG_BIT(30)
> > -#define ICL_DELAY_PMRSPREG_BIT(22)
> > -#define DISABLE_FLR_SRCREG_BIT(15)
> > -#define MASK_WAKEMEM REG_BIT(13)
> > +#define GEN8_CHICKEN_DCPR_1 _MMIO(0x46430)
> > +#define SKL
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
On Wed, 2022-02-16 at 12:07 +0200, Ville Syrjälä wrote: > On Wed, Feb 16, 2022 at 09:36:02AM +, Hogander, Jouni wrote: > > On Wed, 2022-02-16 at 10:50 +0200, Ville Syrjälä wrote: > > > On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote: > > > > From: Jouni Högander > > > > > > > > Currently ICL_PHY_MISC macro is returning offset 0x64C10 for > > > > PHY_E > > > > port. Correct offset is 0x64C14. > > > > > > Why is it PHY_E and not PHY_F? > > > > This is a valid question. It seems we have followed > > intel_phy_is_snps() > > here: > > > > // snip > > else if (IS_DG2(dev_priv)) > > /* > > * All four "combo" ports and the TC1 port (PHY E) use > > * Synopsis PHYs. > > */ > > return phy <= PHY_E; > > // snip > > > > According to spec port E is "No connection". Better place to fix > > this > > could be intel_phy_is_snps() itself? > > I think the crucial question is where are all the places that > the results of intel_port_to_phy() get used. > > I do see that for all the actual snps phy registers we > do want PHY_E, but maybe it would be better to have a local > SNPS_PHY enum just for intel_snps_phy.c, and leave the other > phy thing for everything else? > > Not sure if there is some other register we index with the > phy that specifically wants PHY_E? I went through registers accesses in intel_snps_phy.c. It is actually only this one register which offset is wrong with PHY_E. Everything else seems to be assuming PHY_E including those SNPS_* registers (as you mentioned). I'm starting to think it would be overkill to open up this phy enum for this purpose. I would propose to stick with current patch. Maybe just update commit message. What do you think? > > Also it kinda looks to me like for VBT port mapping we also > want PHY_F essentially since the modern platforms make the > VBT port mapping PHY based and xelpd_port_mapping() uses > PORT_TC1<->DVO_PORT_*F. Not that we actually use enum phy > in the VBT code atm, but I'm thinking we probably should > since it might allow us to get rid of all those different > mapping tables. Though the whole intel_port_to_phy() > disaster needs to get cleaned up first IMO. > BR, Jouni Högander
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset
On Wed, Feb 16, 2022 at 02:11:54PM +, Hogander, Jouni wrote: > On Wed, 2022-02-16 at 12:07 +0200, Ville Syrjälä wrote: > > On Wed, Feb 16, 2022 at 09:36:02AM +, Hogander, Jouni wrote: > > > On Wed, 2022-02-16 at 10:50 +0200, Ville Syrjälä wrote: > > > > On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote: > > > > > From: Jouni Högander > > > > > > > > > > Currently ICL_PHY_MISC macro is returning offset 0x64C10 for > > > > > PHY_E > > > > > port. Correct offset is 0x64C14. > > > > > > > > Why is it PHY_E and not PHY_F? > > > > > > This is a valid question. It seems we have followed > > > intel_phy_is_snps() > > > here: > > > > > > // snip > > > else if (IS_DG2(dev_priv)) > > > /* > > >* All four "combo" ports and the TC1 port (PHY E) use > > >* Synopsis PHYs. > > >*/ > > > return phy <= PHY_E; > > > // snip > > > > > > According to spec port E is "No connection". Better place to fix > > > this > > > could be intel_phy_is_snps() itself? > > > > I think the crucial question is where are all the places that > > the results of intel_port_to_phy() get used. > > > > I do see that for all the actual snps phy registers we > > do want PHY_E, but maybe it would be better to have a local > > SNPS_PHY enum just for intel_snps_phy.c, and leave the other > > phy thing for everything else? > > > > Not sure if there is some other register we index with the > > phy that specifically wants PHY_E? > > I went through registers accesses in intel_snps_phy.c. It is actually > only this one register which offset is wrong with PHY_E. Everything > else seems to be assuming PHY_E including those SNPS_* registers (as > you mentioned). I'm starting to think it would be overkill to open up > this phy enum for this purpose. I would propose to stick with current > patch. Maybe just update commit message. What do you think? I would put it the other way. It is *only* the SNPS PHY IP registers that use the wonky offsets (unless you found some others?). Everythting on the Intel IP side wants it to be PHY_F. So still would make more sense to me to add a new enum for the SNPS PHY instance and remap across the boundary. Otherwise we're just propagating this madness everwhere rather than containing in the SNPS PHY implementation. -- Ville Syrjälä Intel
[Intel-gfx] [PATCH 1/4] drm/i915/dsi: disassociate VBT video transfer mode from register values
The VBT DSI video transfer mode field values have been defined in terms
of the VLV MIPI_VIDEO_MODE_FORMAT register. The ICL DSI code maps that
to ICL DSI_TRANS_FUNC_CONF() register. The values are the same, though
the shift is different.
Make a clean break and disassociate the values from each other. Assume
the values can be different, and translate the VBT value to VLV and ICL
register values as needed. Use the existing macros from intel_bios.h.
This will be useful in splitting the DSI register macros to files by DSI
implementation.
Cc: Matt Roper
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 11 +++
drivers/gpu/drm/i915/display/intel_dsi.h | 4 +--
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 10 +++---
drivers/gpu/drm/i915/display/vlv_dsi.c | 33
4 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 2d5bb9195b20..479d5e1165d9 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -788,14 +788,14 @@ gen11_dsi_configure_transcoder(struct intel_encoder
*encoder,
/* program DSI operation mode */
if (is_vid_mode(intel_dsi)) {
tmp &= ~OP_MODE_MASK;
- switch (intel_dsi->video_mode_format) {
+ switch (intel_dsi->video_mode) {
default:
- MISSING_CASE(intel_dsi->video_mode_format);
+ MISSING_CASE(intel_dsi->video_mode);
fallthrough;
- case VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS:
+ case NON_BURST_SYNC_EVENTS:
tmp |= VIDEO_MODE_SYNC_EVENT;
break;
- case VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE:
+ case NON_BURST_SYNC_PULSE:
tmp |= VIDEO_MODE_SYNC_PULSE;
break;
}
@@ -960,8 +960,7 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder
*encoder,
/* TRANS_HSYNC register to be programmed only for video mode */
if (is_vid_mode(intel_dsi)) {
- if (intel_dsi->video_mode_format ==
- VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE) {
+ if (intel_dsi->video_mode == NON_BURST_SYNC_PULSE) {
/* BSPEC: hsync size should be atleast 16 pixels */
if (hsync_size < 16)
drm_err(&dev_priv->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h
b/drivers/gpu/drm/i915/display/intel_dsi.h
index a3a906cb097e..eafef0a87fea 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi.h
+++ b/drivers/gpu/drm/i915/display/intel_dsi.h
@@ -79,8 +79,8 @@ struct intel_dsi {
*/
enum mipi_dsi_pixel_format pixel_format;
- /* video mode format for MIPI_VIDEO_MODE_FORMAT register */
- u32 video_mode_format;
+ /* NON_BURST_SYNC_PULSE, NON_BURST_SYNC_EVENTS, or BURST_MODE */
+ int video_mode;
/* eot for MIPI_EOT_DISABLE register */
u8 eotp_pkt;
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index a85574c413e8..a1cd86e53e21 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -675,11 +675,11 @@ void intel_dsi_log_params(struct intel_dsi *intel_dsi)
drm_dbg_kms(&i915->drm, "Lane count %d\n", intel_dsi->lane_count);
drm_dbg_kms(&i915->drm, "DPHY param reg 0x%x\n", intel_dsi->dphy_reg);
drm_dbg_kms(&i915->drm, "Video mode format %s\n",
- intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ?
+ intel_dsi->video_mode == NON_BURST_SYNC_PULSE ?
"non-burst with sync pulse" :
- intel_dsi->video_mode_format ==
VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS ?
+ intel_dsi->video_mode == NON_BURST_SYNC_EVENTS ?
"non-burst with sync events" :
- intel_dsi->video_mode_format == VIDEO_MODE_BURST ?
+ intel_dsi->video_mode == BURST_MODE ?
"burst" : "");
drm_dbg_kms(&i915->drm, "Burst mode ratio %d\n",
intel_dsi->burst_mode_ratio);
@@ -739,7 +739,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
intel_dsi->dual_link = mipi_config->dual_link;
intel_dsi->pixel_overlap = mipi_config->pixel_overlap;
intel_dsi->operation_mode = mipi_config->is_cmd_mode;
- intel_dsi->video_mode_format = mipi_config->video_transfer_mode;
+ intel_dsi->video_mode = mipi_config->video_transfer_mode;
intel_dsi->escape_clk_div = mipi_config->byte_clk_s
[Intel-gfx] [PATCH 3/4] drm/i915/reg: split out vlv_dsi_regs.h and vlv_dsi_pll_regs.h
The VLV (including CHV, BXT, and GLK) DSI registers have fairly isolated
usage. Split the register macros to separated files.
Cc: Matt Roper
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +-
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 1 +
drivers/gpu/drm/i915/display/vlv_dsi.c| 1 +
drivers/gpu/drm/i915/display/vlv_dsi_pll.c| 1 +
.../gpu/drm/i915/display/vlv_dsi_pll_regs.h | 109
drivers/gpu/drm/i915/display/vlv_dsi_regs.h | 480 +++
drivers/gpu/drm/i915/gvt/handlers.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 574 --
8 files changed, 595 insertions(+), 575 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/vlv_dsi_pll_regs.h
create mode 100644 drivers/gpu/drm/i915/display/vlv_dsi_regs.h
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 59961621fe4a..ff13cfde8664 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -113,9 +113,10 @@
#include "i9xx_plane.h"
#include "skl_scaler.h"
#include "skl_universal_plane.h"
+#include "vlv_dsi.h"
#include "vlv_dsi_pll.h"
+#include "vlv_dsi_regs.h"
#include "vlv_sideband.h"
-#include "vlv_dsi.h"
static void intel_set_transcoder_timings(const struct intel_crtc_state
*crtc_state);
static void intel_set_pipe_src_size(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index a1cd86e53e21..6b4a27372c82 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -44,6 +44,7 @@
#include "intel_dsi.h"
#include "intel_dsi_vbt.h"
#include "vlv_dsi.h"
+#include "vlv_dsi_regs.h"
#include "vlv_sideband.h"
#define MIPI_TRANSFER_MODE_SHIFT 0
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index f0c38173491e..0d936f658b3f 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -44,6 +44,7 @@
#include "skl_scaler.h"
#include "vlv_dsi.h"
#include "vlv_dsi_pll.h"
+#include "vlv_dsi_regs.h"
#include "vlv_sideband.h"
/* return pixels in terms of txbyteclkhs */
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
index 1b81797dd02e..df880f44700a 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
@@ -32,6 +32,7 @@
#include "intel_display_types.h"
#include "intel_dsi.h"
#include "vlv_dsi_pll.h"
+#include "vlv_dsi_pll_regs.h"
#include "vlv_sideband.h"
static const u16 lfsr_converts[] = {
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll_regs.h
b/drivers/gpu/drm/i915/display/vlv_dsi_pll_regs.h
new file mode 100644
index ..45590e14e54b
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/vlv_dsi_pll_regs.h
@@ -0,0 +1,109 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __VLV_DSI_PLL_REGS_H__
+#define __VLV_DSI_PLL_REGS_H__
+
+#include "vlv_dsi_regs.h"
+
+#define MIPIO_TXESC_CLK_DIV1 _MMIO(0x160004)
+#define GLK_TX_ESC_CLK_DIV1_MASK 0x3FF
+#define MIPIO_TXESC_CLK_DIV2 _MMIO(0x160008)
+#define GLK_TX_ESC_CLK_DIV2_MASK 0x3FF
+
+#define BXT_MAX_VAR_OUTPUT_KHZ 39500
+
+#define BXT_MIPI_CLOCK_CTL _MMIO(0x46090)
+#define BXT_MIPI1_DIV_SHIFT 26
+#define BXT_MIPI2_DIV_SHIFT 10
+#define BXT_MIPI_DIV_SHIFT(port) \
+ _MIPI_PORT(port, BXT_MIPI1_DIV_SHIFT, \
+ BXT_MIPI2_DIV_SHIFT)
+
+/* TX control divider to select actual TX clock output from (8x/var) */
+#define BXT_MIPI1_TX_ESCLK_SHIFT 26
+#define BXT_MIPI2_TX_ESCLK_SHIFT 10
+#define BXT_MIPI_TX_ESCLK_SHIFT(port) \
+ _MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_SHIFT, \
+ BXT_MIPI2_TX_ESCLK_SHIFT)
+#define BXT_MIPI1_TX_ESCLK_FIXDIV_MASK(0x3F << 26)
+#define BXT_MIPI2_TX_ESCLK_FIXDIV_MASK(0x3F << 10)
+#define BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port) \
+ _MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_FIXDIV_MASK, \
+ BXT_MIPI2_TX_ESCLK_FIXDIV_MASK)
+#define BXT_MIPI_TX_ESCLK_DIVIDER(port, val) \
+ (((val) & 0x3F) << BXT_MIPI_TX_ESCLK_SHIFT(port))
+/* RX upper control divider to select actual RX clock output from 8x */
+#define BXT_MIPI1_RX_ESCLK_UPPER_SHIFT21
+#define BXT_MIPI2_RX_ESCLK_UPPER_SHIFT5
+#define BXT_MIPI_RX_ESCLK_UPPER_SHIFT(port) \
+ _MIPI_PORT(port, BXT_MIPI1_RX_ESCLK_UPPER_SHIFT, \
+
[Intel-gfx] [PATCH 4/4] drm/i915/reg: split out icl_dsi_regs.h
The ICL DSI registers have fairly isolated usage. Split the register macros to a separate file. Cc: Matt Roper Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/icl_dsi.c | 1 + drivers/gpu/drm/i915/display/icl_dsi_regs.h | 342 drivers/gpu/drm/i915/i915_irq.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 333 --- 4 files changed, 344 insertions(+), 333 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/icl_dsi_regs.h diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c index 3c01565e62b2..13b07c6fd6be 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi.c +++ b/drivers/gpu/drm/i915/display/icl_dsi.c @@ -29,6 +29,7 @@ #include #include "icl_dsi.h" +#include "icl_dsi_regs.h" #include "intel_atomic.h" #include "intel_backlight.h" #include "intel_combo_phy.h" diff --git a/drivers/gpu/drm/i915/display/icl_dsi_regs.h b/drivers/gpu/drm/i915/display/icl_dsi_regs.h new file mode 100644 index ..f78f28b8dd94 --- /dev/null +++ b/drivers/gpu/drm/i915/display/icl_dsi_regs.h @@ -0,0 +1,342 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2022 Intel Corporation + */ + +#ifndef __ICL_DSI_REGS_H__ +#define __ICL_DSI_REGS_H__ + +#include "i915_reg_defs.h" + +/* Gen11 DSI */ +#define _MMIO_DSI(tc, dsi0, dsi1) _MMIO_TRANS((tc) - TRANSCODER_DSI_0, \ + dsi0, dsi1) +#define _ICL_DSI_ESC_CLK_DIV0 0x6b090 +#define _ICL_DSI_ESC_CLK_DIV1 0x6b890 +#define ICL_DSI_ESC_CLK_DIV(port) _MMIO_PORT((port), \ + _ICL_DSI_ESC_CLK_DIV0, \ + _ICL_DSI_ESC_CLK_DIV1) +#define _ICL_DPHY_ESC_CLK_DIV0 0x162190 +#define _ICL_DPHY_ESC_CLK_DIV1 0x6C190 +#define ICL_DPHY_ESC_CLK_DIV(port) _MMIO_PORT((port), \ + _ICL_DPHY_ESC_CLK_DIV0, \ + _ICL_DPHY_ESC_CLK_DIV1) +#define ICL_BYTE_CLK_PER_ESC_CLK_MASK (0x1f << 16) +#define ICL_BYTE_CLK_PER_ESC_CLK_SHIFT16 +#define ICL_ESC_CLK_DIV_MASK 0x1ff +#define ICL_ESC_CLK_DIV_SHIFT 0 +#define DSI_MAX_ESC_CLK2 /* in KHz */ + +#define _ADL_MIPIO_REG 0x180 +#define ADL_MIPIO_DW(port, dw) _MMIO(_ICL_COMBOPHY(port) + _ADL_MIPIO_REG + 4 * (dw)) +#define TX_ESC_CLK_DIV_PHY_SEL REGBIT(16) +#define TX_ESC_CLK_DIV_PHY_MASK REG_GENMASK(23, 16) +#define TX_ESC_CLK_DIV_PHY REG_FIELD_PREP(TX_ESC_CLK_DIV_PHY_MASK, 0x7f) + +#define _DSI_CMD_FRMCTL_0 0x6b034 +#define _DSI_CMD_FRMCTL_1 0x6b834 +#define DSI_CMD_FRMCTL(port) _MMIO_PORT(port,\ + _DSI_CMD_FRMCTL_0,\ + _DSI_CMD_FRMCTL_1) +#define DSI_FRAME_UPDATE_REQUEST (1 << 31) +#define DSI_PERIODIC_FRAME_UPDATE_ENABLE (1 << 29) +#define DSI_NULL_PACKET_ENABLE (1 << 28) +#define DSI_FRAME_IN_PROGRESS(1 << 0) + +#define _DSI_INTR_MASK_REG_0 0x6b070 +#define _DSI_INTR_MASK_REG_1 0x6b870 +#define DSI_INTR_MASK_REG(port)_MMIO_PORT(port,\ + _DSI_INTR_MASK_REG_0,\ + _DSI_INTR_MASK_REG_1) + +#define _DSI_INTR_IDENT_REG_0 0x6b074 +#define _DSI_INTR_IDENT_REG_1 0x6b874 +#define DSI_INTR_IDENT_REG(port) _MMIO_PORT(port,\ + _DSI_INTR_IDENT_REG_0,\ + _DSI_INTR_IDENT_REG_1) +#define DSI_TE_EVENT (1 << 31) +#define DSI_RX_DATA_OR_BTA_TERMINATED(1 << 30) +#define DSI_TX_DATA (1 << 29) +#define DSI_ULPS_ENTRY_DONE (1 << 28) +#define DSI_NON_TE_TRIGGER_RECEIVED (1 << 27) +#define DSI_HOST_CHKSUM_ERROR(1 << 26) +#define DSI_HOST_MULTI_ECC_ERROR (1 << 25) +#define DSI_HOST_SINGL_ECC_ERROR (1 << 24) +#define DSI_HOST_CONTENTION_DETECTED (1 << 23) +#define DSI_HOST_FALSE_CONTROL_ERROR (1 << 22) +#define DSI_HOST_TIMEOUT_ERROR (1 << 21) +#define DSI_HOST_LOW_POWER_TX_SYNC_ERROR (1 << 20) +#define DSI_HOST_ESCAPE_MODE_ENTRY_ERROR (1 << 19) +#define DSI_FRAME_UPDATE_DONE(1 << 16) +#define DSI_PROTOCOL_VIOLATION_REPORTED (1 << 15) +#define DSI_INVALID_TX_LENGTH(1 << 13) +#define DSI_INVALID_VC (1 << 12) +#define DSI_INVALID_DATA_TYPE(1 <<
[Intel-gfx] [PATCH 2/4] drm/i915/dsi: add separate init timer mask definition for ICL DSI
Having a separate definition will be useful for splitting VLV and ICL
register files.
Cc: Matt Roper
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h| 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 479d5e1165d9..3c01565e62b2 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -570,7 +570,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder,
/* Program T-INIT master registers */
for_each_dsi_port(port, intel_dsi->ports) {
tmp = intel_de_read(dev_priv, ICL_DSI_T_INIT_MASTER(port));
- tmp &= ~MASTER_INIT_TIMER_MASK;
+ tmp &= ~DSI_T_INIT_MASTER_MASK;
tmp |= intel_dsi->init_count;
intel_de_write(dev_priv, ICL_DSI_T_INIT_MASTER(port), tmp);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4ea1713e6b60..5646c843fd0d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9204,6 +9204,7 @@ enum skl_power_gate {
#define ICL_DSI_T_INIT_MASTER(port)_MMIO_PORT(port,\
_ICL_DSI_T_INIT_MASTER_0,\
_ICL_DSI_T_INIT_MASTER_1)
+#define DSI_T_INIT_MASTER_MASK REG_GENMASK(15, 0)
#define _DPHY_CLK_TIMING_PARAM_0 0x162180
#define _DPHY_CLK_TIMING_PARAM_1 0x6c180
--
2.30.2
Re: [Intel-gfx] [PATCH topic/for-CI] drm/i915: Add DG2 PCI IDs
Reviewed-by: Caz Yokoyama
-caz
On Tue, 2022-02-15 at 13:45 -0800, Matt Roper wrote:
> DG2 hardware will start showing up in CI shortly; let's make sure
> it's
> recognized by the driver.
>
> Bspec: 44477
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> drivers/gpu/drm/i915/intel_device_info.c | 21 ++
> include/drm/i915_pciids.h| 27
>
> 3 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> index 8246cbe9b01d..91677a9f330c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1038,7 +1038,6 @@ static const struct intel_device_info
> xehpsdv_info = {
> .require_force_probe = 1,
> };
>
> -__maybe_unused
> static const struct intel_device_info dg2_info = {
> XE_HP_FEATURES,
> XE_HPM_FEATURES,
> @@ -1137,6 +1136,7 @@ static const struct pci_device_id pciidlist[] =
> {
> INTEL_ADLN_IDS(&adl_p_info),
> INTEL_DG1_IDS(&dg1_info),
> INTEL_RPLS_IDS(&adl_s_info),
> + INTEL_DG2_IDS(&dg2_info),
> {0, 0, 0}
> };
> MODULE_DEVICE_TABLE(pci, pciidlist);
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 94da5aa37391..ae13bc3c7970 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -178,6 +178,18 @@ static const u16 subplatform_rpls_ids[] = {
> INTEL_RPLS_IDS(0),
> };
>
> +static const u16 subplatform_g10_ids[] = {
> + INTEL_DG2_G10_IDS(0),
> +};
> +
> +static const u16 subplatform_g11_ids[] = {
> + INTEL_DG2_G11_IDS(0),
> +};
> +
> +static const u16 subplatform_g12_ids[] = {
> + INTEL_DG2_G12_IDS(0),
> +};
> +
> static bool find_devid(u16 id, const u16 *p, unsigned int num)
> {
> for (; num; num--, p++) {
> @@ -220,6 +232,15 @@ void intel_device_info_subplatform_init(struct
> drm_i915_private *i915)
> } else if (find_devid(devid, subplatform_rpls_ids,
> ARRAY_SIZE(subplatform_rpls_ids))) {
> mask = BIT(INTEL_SUBPLATFORM_RPL_S);
> + } else if (find_devid(devid, subplatform_g10_ids,
> + ARRAY_SIZE(subplatform_g10_ids))) {
> + mask = BIT(INTEL_SUBPLATFORM_G10);
> + } else if (find_devid(devid, subplatform_g11_ids,
> + ARRAY_SIZE(subplatform_g11_ids))) {
> + mask = BIT(INTEL_SUBPLATFORM_G11);
> + } else if (find_devid(devid, subplatform_g12_ids,
> + ARRAY_SIZE(subplatform_g12_ids))) {
> + mask = BIT(INTEL_SUBPLATFORM_G12);
> }
>
> if (IS_TIGERLAKE(i915)) {
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 533890dc9da1..3609f3254f24 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -681,4 +681,31 @@
> INTEL_VGA_DEVICE(0xA788, info), \
> INTEL_VGA_DEVICE(0xA789, info)
>
> +/* DG2 */
> +#define INTEL_DG2_G10_IDS(info) \
> + INTEL_VGA_DEVICE(0x5690, info), \
> + INTEL_VGA_DEVICE(0x5691, info), \
> + INTEL_VGA_DEVICE(0x5692, info), \
> + INTEL_VGA_DEVICE(0x56A0, info), \
> + INTEL_VGA_DEVICE(0x56A1, info), \
> + INTEL_VGA_DEVICE(0x56A2, info)
> +
> +#define INTEL_DG2_G11_IDS(info) \
> + INTEL_VGA_DEVICE(0x5693, info), \
> + INTEL_VGA_DEVICE(0x5694, info), \
> + INTEL_VGA_DEVICE(0x5695, info), \
> + INTEL_VGA_DEVICE(0x56A5, info), \
> + INTEL_VGA_DEVICE(0x56A6, info), \
> + INTEL_VGA_DEVICE(0x56B0, info), \
> + INTEL_VGA_DEVICE(0x56B1, info)
> +
> +#define INTEL_DG2_G12_IDS(info) \
> + INTEL_VGA_DEVICE(0x56A3, info), \
> + INTEL_VGA_DEVICE(0x56A4, info)
> +
> +#define INTEL_DG2_IDS(info) \
> + INTEL_DG2_G10_IDS(info), \
> + INTEL_DG2_G11_IDS(info), \
> + INTEL_DG2_G12_IDS(info)
> +
> #endif /* _I915_PCIIDS_H */
Re: [Intel-gfx] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members
On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote:
> On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote:
> > There is a regular need in the kernel to provide a way to declare
> > having a dynamically sized set of trailing elements in a structure.
> > Kernel code should always use “flexible array members”[1] for these
> > cases. The older style of one-element or zero-length arrays should
> > no longer be used[2].
> >
> > This code was transformed with the help of Coccinelle:
> > (next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file
> > script.cocci --include-headers --dir . > output.patch)
> >
> > @@
> > identifier S, member, array;
> > type T1, T2;
> > @@
> >
> > struct S {
> > ...
> > T1 member;
> > T2 array[
> > - 0
> > ];
> > };
>
> These all look trivially correct to me. Only two didn't have the end of
> the struct visible in the patch, and checking those showed them to be
> trailing members as well, so:
>
> Reviewed-by: Kees Cook
I'll add this to my -next tree.
Thanks!
--
Gustavo
[Intel-gfx] [PATCH] drm/i915/gt: fix unsigned integer to signed assignment
Eliminate the follow smatch warning:
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4640
guc_create_virtual() warn: assigning (-2) to unsigned variable
've->base.instance'.
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4641
guc_create_virtual() warn: assigning (-2) to unsigned variable
've->base.uabi_instance'.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 36365bdbe1ee..dc7cc06c68e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -328,10 +328,10 @@ struct intel_engine_cs {
intel_engine_mask_t logical_mask;
u8 class;
- u8 instance;
+ s8 instance;
u16 uabi_class;
- u16 uabi_instance;
+ s16 uabi_instance;
u32 uabi_capabilities;
u32 context_size;
--
2.20.1.7.g153144c
Re: [Intel-gfx] [PATCH v2] drm/i915: fix build issue when using clang
On Mon, Feb 14, 2022 at 11:58:20AM -0800, Tong Zhang wrote:
> drm/i915 adds some extra cflags, namely -Wall, which causes
> instances of -Wformat-security to appear when building with clang, even
> though this warning is turned off kernel-wide in the main Makefile:
>
> > drivers/gpu/drm/i915/gt/intel_gt.c:983:2: error: format string is not a
> > string literal (potentially insecure) [-Werror,-Wformat-security]
> > GEM_TRACE("ERROR\n");
> > ^~~~
> > ./drivers/gpu/drm/i915/i915_gem.h:76:24: note: expanded from macro
> > 'GEM_TRACE'
> > #define GEM_TRACE(...) trace_printk(__VA_ARGS__)
> >^
> > ./include/linux/kernel.h:369:3: note: expanded from macro 'trace_printk'
> > do_trace_printk(fmt, ##__VA_ARGS__);\
> > ^~~
> > ./include/linux/kernel.h:383:30: note: expanded from macro 'do_trace_printk'
> > __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
> > ^~~~
> >drivers/gpu/drm/i915/gt/intel_gt.c:983:2: note: treat the string as an
> >argument to avoid this
>
> This does not happen with GCC because it does not enable
> -Wformat-security with -Wall. Disable -Wformat-security within the i915
> Makefile so that these warnings do not show up with clang.
>
> Signed-off-by: Tong Zhang
Given this is not enabled for GCC and it is disabled in the main
Makefile:
Reviewed-by: Nathan Chancellor
Additionally, it seems like trace_printk() is designed to be able to
take a string literal without a format argument, so this should be fine.
> ---
>
> v2: revise commit message
>
> drivers/gpu/drm/i915/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 1b62b9f65196..c04e05a3d39f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -13,6 +13,7 @@
> # will most likely get a sudden build breakage... Hopefully we will fix
> # new warnings before CI updates!
> subdir-ccflags-y := -Wall -Wextra
> +subdir-ccflags-y += -Wno-format-security
> subdir-ccflags-y += -Wno-unused-parameter
> subdir-ccflags-y += -Wno-type-limits
> subdir-ccflags-y += -Wno-missing-field-initializers
> --
> 2.25.1
>
>
[Intel-gfx] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
This code was transformed with the help of Coccinelle:
(next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file
script.cocci --include-headers --dir . > output.patch)
@@
identifier S, member, array;
type T1, T2;
@@
struct S {
...
T1 member;
T2 array[
- 0
];
};
UAPI and wireless changes were intentionally excluded from this patch
and will be sent out separately.
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2]
https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays
Link: https://github.com/KSPP/linux/issues/78
Signed-off-by: Gustavo A. R. Silva
---
Hi all,
I'm expecting to carry this patch in my tree, so it'd be great to
get some Acks. And given the size of the patch, I'm only sending
this to mailing lists.
Thanks!
arch/alpha/include/asm/hwrpb.h| 2 +-
arch/ia64/include/asm/sal.h | 2 +-
arch/s390/include/asm/ccwgroup.h | 2 +-
arch/s390/include/asm/chsc.h | 2 +-
arch/s390/include/asm/eadm.h | 2 +-
arch/s390/include/asm/fcx.h | 4 ++--
arch/s390/include/asm/idals.h | 2 +-
arch/s390/include/asm/sclp.h | 2 +-
arch/s390/include/asm/sysinfo.h | 6 +++---
arch/sh/include/asm/thread_info.h | 2 +-
arch/sparc/include/asm/vio.h | 10 +-
arch/um/include/shared/net_kern.h | 2 +-
arch/x86/include/asm/microcode_amd.h | 2 +-
arch/x86/include/asm/microcode_intel.h| 4 ++--
arch/x86/include/asm/pci.h| 2 +-
arch/x86/include/asm/pci_x86.h| 2 +-
arch/xtensa/include/asm/bootparam.h | 2 +-
drivers/crypto/caam/pdb.h | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
drivers/gpu/drm/nouveau/include/nvfw/hs.h | 2 +-
.../hwtracing/coresight/coresight-config.h| 2 +-
drivers/misc/bcm-vk/bcm_vk.h | 2 +-
.../misc/habanalabs/include/common/cpucp_if.h | 6 +++---
.../habanalabs/include/gaudi/gaudi_packets.h | 4 ++--
.../habanalabs/include/goya/goya_packets.h| 4 ++--
.../net/ethernet/freescale/enetc/enetc_hw.h | 2 +-
drivers/net/ethernet/i825xx/sun3_82586.h | 2 +-
.../net/ethernet/marvell/octeontx2/af/npc.h | 6 +++---
drivers/net/ethernet/qlogic/qed/qed_mfw_hsi.h | 2 +-
drivers/net/ethernet/ti/davinci_mdio.c| 2 +-
drivers/scsi/dpt/dpti_i2o.h | 2 +-
drivers/scsi/elx/libefc_sli/sli4.h| 20 +--
drivers/scsi/mpi3mr/mpi3mr.h | 2 +-
drivers/scsi/qla2xxx/qla_bsg.h| 4 ++--
drivers/scsi/qla2xxx/qla_def.h| 2 +-
drivers/scsi/qla2xxx/qla_edif_bsg.h | 4 ++--
drivers/scsi/qla2xxx/qla_fw.h | 2 +-
drivers/scsi/qla4xxx/ql4_fw.h | 2 +-
drivers/staging/r8188eu/include/ieee80211.h | 6 +++---
drivers/staging/r8188eu/include/rtw_cmd.h | 10 +-
drivers/staging/rtl8712/rtl871x_cmd.h | 8
drivers/staging/rtl8723bs/include/ieee80211.h | 2 +-
drivers/staging/rtl8723bs/include/rtw_cmd.h | 2 +-
.../include/linux/raspberrypi/vchiq.h | 2 +-
drivers/visorbus/vbuschannel.h| 2 +-
fs/cifs/ntlmssp.h | 2 +-
fs/ext4/fast_commit.h | 4 ++--
fs/ksmbd/ksmbd_netlink.h | 2 +-
fs/ksmbd/ntlmssp.h| 6 +++---
fs/ksmbd/smb2pdu.h| 8
fs/ksmbd/transport_rdma.c | 2 +-
fs/ksmbd/xattr.h | 2 +-
fs/xfs/scrub/attr.h | 2 +-
include/acpi/actbl2.h | 2 +-
include/asm-generic/tlb.h | 4 ++--
include/linux/greybus/greybus_manifest.h | 4 ++--
include/linux/greybus/hd.h| 2 +-
include/linux/greybus/module.h| 2 +-
include/linux/i3c/ccc.h | 6 +++---
include/linux/mlx5/mlx5_ifc_fpga.h| 2 +-
include/linux/platform_data/brcmfmac.h| 2 +-
.../linux/platform_data/cros_ec_commands.h| 2 +-
include/net/bluetooth/mgmt.h | 2 +-
include/net/ioam6.h | 2 +-
include/sound/sof/channel_map.h | 4 ++--
scripts/dtc/libfdt/fdt.h | 4 ++--
sound/soc/intel/atom/sst-mfld-dsp.h | 4 ++--
sound/soc/intel/skylake/skl-topology.h| 2 +-
tools/lib/perf/include/perf/event.h | 2 +-
69 files ch
Re: [Intel-gfx] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members
On Tue, Feb 15, 2022 at 09:19:29PM +0200, Leon Romanovsky wrote: > On Tue, Feb 15, 2022 at 01:21:10PM -0600, Gustavo A. R. Silva wrote: > > On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote: > > > On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote: > > > > > > These all look trivially correct to me. Only two didn't have the end of > > > the struct visible in the patch, and checking those showed them to be > > > trailing members as well, so: > > > > > > Reviewed-by: Kees Cook > > > > I'll add this to my -next tree. > > I would like to ask you to send mlx5 patch separately to netdev. We are > working > to delete that file completely and prefer to avoid from unnecessary merge > conflicts. Oh OK. Sure thing; I will do so. Thanks -- Gustavo
Re: [Intel-gfx] [PATCH v7 1/5] drm/i915/gsc: add gsc as a mei auxiliary device
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Wednesday, February 16, 2022 14:04
> To: Usyskin, Alexander ; Greg Kroah-
> Hartman ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter
> Cc: linux-ker...@vger.kernel.org; Winkler, Tomas
> ; Lubart, Vitaly ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v7 1/5] drm/i915/gsc: add gsc as a mei
> auxiliary device
>
>
>
> On 15/02/2022 15:22, Usyskin, Alexander wrote:
>
> >>> +{
> >>> + irq_set_chip_and_handler_name(irq, &gsc_irq_chip,
> >>> + handle_simple_irq, "gsc_irq_handler");
> >>> +
> >>> + return irq_set_chip_data(irq, dev_priv);
> >>
> >> I am not familiar with this interrupt scheme - does dev_priv get used at
> >> all by handle_simple_irq, or anyone, after being set here?
>
> What about this? Is dev_priv required or you could pass in NULL just as
> well?
>
It is not used, will remove
> >>
> >>> +}
> >>> +
> >>> +struct intel_gsc_def {
> >>> + const char *name;
> >>> + const unsigned long bar;
> >>
> >> Unusual, why const out of curiosity? And is it "bar" or "base" would be
> >> more accurate?
> >>
> > Some leftover, thanks for spotting this!
> > It is a base of bar. I prefer bar name here. But not really matter.
>
> Is it?
>
> + adev->bar.start = def->bar + pdev->resource[0].start;
>
> Looks like offset on top of BAR, no?
>
Offset on top of DG bar; but start of HECI1/2 bar too.
> >>> +{
> >>> + struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> >>> + struct mei_aux_device *adev;
> >>> + struct auxiliary_device *aux_dev;
> >>> + const struct intel_gsc_def *def;
> >>> + int ret;
> >>> +
> >>> + intf->irq = -1;
> >>> + intf->id = intf_id;
> >>> +
> >>> + if (intf_id == 0 && !HAS_HECI_PXP(dev_priv))
> >>> + return;
> >>
> >> Isn't inf_id == 0 always a bug with this patch, regardless of
> >> HAS_HECI_PXP, since the support is incomplete in this patch? If so I'd
> >> be more comfortable with a plain drm_WARN_ON_ONCE(intf_id == 0).
> >>
> > There will be patches for other cards that have pxp as soon as this is
> reviewed.
> > It is better to have infra prepared for two heads.
>
> My point is things are half-prepared since you don't have the id 0 in
> the array, regardless of the HAS_HECI_PXP. Yes it can't be true now, but
> if you add a patch which enables it to be true, you have to modify the
> array at the same time or risk a broken patch in the middle.
>
> I don't see the point of the condition making it sound like there are
> two criteria to enter below, while in fact there is only one in current
> code, and that it that it must not be entered because array is incomplete!
>
We initialize both cells in gsc->intf array, the first one with defaults (two
lines before this line)
for systems without working PXP, like DG1.
The code on GSC level does not know that we don't have PXP and don't want to
know.
> >>> +
> >>> + if (!HAS_HECI_GSC(gt->i915))
> >>> + return;
> >>
> >> Likewise?
> >>
> >>> +
> >>> + if (gt->gsc.intf[intf_id].irq <= 0) {
> >>> + DRM_ERROR_RATELIMITED("error handling GSC irq: irq not
> >> set");
> >>
> >> Like this, but use logging functions which say which device please.
> >>
> > drm_err_ratelimited fits here?
>
> AFAICT it would be a programming bug and not something that can happen
> at runtime hence drm_warn_on_once sounds correct for both.
>
Sure, will do
> >>>}
> >>> @@ -182,6 +185,8 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> >>> /* Disable RCS, BCS, VCS and VECS class engines. */
> >>> intel_uncore_write(uncore, GEN11_RENDER_COPY_INTR_ENABLE,
> >> 0);
> >>> intel_uncore_write(uncore, GEN11_VCS_VECS_INTR_ENABLE,0);
> >>> + if (HAS_HECI_GSC(gt->i915))
> >>> + intel_uncore_write(uncore,
> >> GEN11_GUNIT_CSME_INTR_ENABLE, 0);
> >>>
> >>> /* Restore masks irqs on RCS, BCS, VCS and VECS engines. */
> >>> intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~0);
> >>> @@ -195,6 +200,8 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> >>> intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK,
> >>~0);
> >>> if (HAS_ENGINE(gt, VECS2) || HAS_ENGINE(gt, VECS3))
> >>> intel_uncore_write(uncore,
> >> GEN12_VECS2_VECS3_INTR_MASK, ~0);
> >>> + if (HAS_HECI_GSC(gt->i915))
> >>> + intel_uncore_write(uncore,
> >> GEN11_GUNIT_CSME_INTR_MASK, ~0);
> >>>
> >>> intel_uncore_write(uncore,
> >> GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
> >>> intel_uncore_write(uncore,
> >> GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
> >>> @@ -209,6 +216,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
> >>>{
> >>> struct intel_uncore *uncore = gt->uncore;
> >>> u32 irqs = GT_RENDER_USER_INTERRUPT;
> >>> + const u32 gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
> >>
> >> Why enable the one which is not supported by the patch? No harm doing
> it?
> >>
> > No
[Intel-gfx] [PATCH] drm/i915/ttm: fixup the mock_bo
When running the mock selftests we currently blow up with:
<6> [299.836278] i915: Running
i915_gem_huge_page_mock_selftests/igt_mock_memory_region_huge_pages
<1> [299.836356] BUG: kernel NULL pointer dereference, address: 00c8
<1> [299.836361] #PF: supervisor read access in kernel mode
<1> [299.836364] #PF: error_code(0x) - not-present page
<6> [299.836367] PGD 0 P4D 0
<4> [299.836369] Oops: [#1] PREEMPT SMP NOPTI
<4> [299.836372] CPU: 1 PID: 1429 Comm: i915_selftest Tainted: G U
5.17.0-rc4-CI-CI_DRM_11227+ #1
<4> [299.836376] Hardware name: Intel(R) Client Systems NUC11TNHi5/NUC11TNBi5,
BIOS TNTGL357.0042.2020.1221.1743 12/21/2020
<4> [299.836380] RIP: 0010:ttm_resource_init+0x57/0x90 [ttm]
<4> [299.836392] RSP: 0018:c90001e4f680 EFLAGS: 00010203
<4> [299.836395] RAX: RBX: c90001e4f708 RCX:
<4> [299.836398] RDX: 888116172528 RSI: c90001e4f6f8 RDI:
<4> [299.836401] RBP: c90001e4f6f8 R08: 01b0 R09:
888116172528
<4> [299.836403] R10: 0001 R11: a4cb2e51 R12:
c90001e4fa90
<4> [299.836406] R13: 888116172528 R14: 888130d7f4b0 R15:
888130d7f400
<4> [299.836409] FS: 7ff241684500() GS:88849fe8()
knlGS:
<4> [299.836412] CS: 0010 DS: ES: CR0: 80050033
<4> [299.836416] CR2: 00c8 CR3: 000107b80001 CR4:
00770ee0
<4> [299.836418] PKRU: 5554
<4> [299.836420] Call Trace:
<4> [299.836422]
<4> [299.836423] i915_ttm_buddy_man_alloc+0x68/0x240 [i915]
ttm_resource_init() now needs to access the bo->bdev, and also wants to
store the bo reference. Try to keep both working. The mock_bo is a hack
so we can interface directly with the ttm managers alloc() and free() hooks for
our mock testing, without invoking other TTM features like eviction,
moves, etc.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5123
Fixes: 0e05fc49c358 ("drm/ttm: add common accounting to the resource mgr v3")
Signed-off-by: Matthew Auld
Cc: Christian König
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index f2b888c16958..30c7e0d1624c 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -200,11 +200,13 @@ intel_region_ttm_resource_alloc(struct
intel_memory_region *mem,
int ret;
mock_bo.base.size = size;
+ mock_bo.bdev = &mem->i915->bdev;
place.flags = flags;
ret = man->func->alloc(man, &mock_bo, &place, &res);
if (ret == -ENOSPC)
ret = -ENXIO;
+ res->bo = NULL; /* Rather blow up, then some uaf */
return ret ? ERR_PTR(ret) : res;
}
@@ -219,6 +221,11 @@ void intel_region_ttm_resource_free(struct
intel_memory_region *mem,
struct ttm_resource *res)
{
struct ttm_resource_manager *man = mem->region_private;
+ struct ttm_buffer_object mock_bo = {};
+
+ mock_bo.base.size = res->num_pages << PAGE_SHIFT;
+ mock_bo.bdev = &mem->i915->bdev;
+ res->bo = &mock_bo;
man->func->free(man, res);
}
--
2.34.1
[Intel-gfx] [PATCH v3 00/16] drm/i915/guc: Refactor ADS access to use iosys_map
original: https://patchwork.freedesktop.org/series/99378/ v2: https://patchwork.freedesktop.org/series/99711/#rev1, https://patchwork.freedesktop.org/series/99711/#rev2 Main changes from previous version: - Unrelated patches to iosys-map conversion have landed - Remove unecessary kernel.h include from iosys-map.h - Rebase on latest drm-tip Original cover letter: While porting i915 to arm64 we noticed some issues accessing lmem. Some writes were getting corrupted and the final state of the buffer didn't have exactly what we wrote. This became evident when enabling GuC submission: depending on the number of engines the ADS struct was being corrupted and GuC would reject it, refusin to initialize. >From Documentation/core-api/bus-virt-phys-mapping.rst: This memory is called "PCI memory" or "shared memory" or "IO memory" or whatever, and there is only one way to access it: the readb/writeb and related functions. You should never take the address of such memory, because there is really nothing you can do with such an address: it's not conceptually in the same memory space as "real memory" at all, so you cannot just dereference a pointer. (Sadly, on x86 it **is** in the same memory space, so on x86 it actually works to just deference a pointer, but it's not portable). When reading or writing words directly to IO memory, in order to be portable the Linux kernel provides the abstraction detailed in section "Differences between I/O access functions" of Documentation/driver-api/device-io.rst. This limits our ability to simply overlay our structs on top a buffer and directly access it since that buffer may come from IO memory rather than system memory. Hence the approach taken in intel_guc_ads.c needs to be refactored. This is not the only place in i915 that need to be changed, but the one causing the most problems, with a real reproducer. This first set of patch focuses on fixing the gem object to pass the ADS After the addition of a few helpers in the dma_buf_map API, most of intel_guc_ads.c can be converted to use it. The exception is the regset initialization: we'd incur into a lot of extra indirection when reading/writing each register. So the regset is converted to use a temporary buffer allocated on probe, which is then copied to its final location when finishing the initialization or on gt reset. [v3: the part unrelated to iosys-map has already landed] Testing on some discrete cards, after this change we can correctly pass the ADS struct to GuC and have it initialized correctly. thanks Lucas De Marchi Lucas De Marchi (16): iosys-map: Add offset to iosys_map_memcpy_to() iosys-map: Add a few more helpers drm/i915/gt: Add helper for shmem copy to iosys_map drm/i915/guc: Keep iosys_map of ads_blob around drm/i915/guc: Add read/write helpers for ADS blob drm/i915/guc: Convert golden context init to iosys_map drm/i915/guc: Convert policies update to iosys_map drm/i915/guc: Convert engine record to iosys_map drm/i915/guc: Convert guc_ads_private_data_reset to iosys_map drm/i915/guc: Convert golden context prep to iosys_map drm/i915/guc: Replace check for golden context size drm/i915/guc: Convert mapping table to iosys_map drm/i915/guc: Convert capture list to iosys_map drm/i915/guc: Convert guc_mmio_reg_state_init to iosys_map drm/i915/guc: Convert __guc_ads_init to iosys_map drm/i915/guc: Remove plain ads_blob pointer drivers/gpu/drm/drm_cache.c | 2 +- drivers/gpu/drm/drm_fb_helper.c | 2 +- drivers/gpu/drm/i915/gt/shmem_utils.c | 32 +++ drivers/gpu/drm/i915/gt/shmem_utils.h | 3 + drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 233 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h| 3 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 +- include/linux/iosys-map.h | 218 +++- 9 files changed, 396 insertions(+), 121 deletions(-) -- 2.35.1
[Intel-gfx] [PATCH v3 04/16] drm/i915/guc: Keep iosys_map of ads_blob around
Convert intel_guc_ads_create() and initialization to use iosys_map
rather than plain pointer and save it in the guc struct. This will help
with additional updates to the ads_blob after the
creation/initialization by abstracting the IO vs system memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 6 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 9d779de16613..f857e9190750 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -6,8 +6,9 @@
#ifndef _INTEL_GUC_H_
#define _INTEL_GUC_H_
-#include
#include
+#include
+#include
#include "intel_uncore.h"
#include "intel_guc_fw.h"
@@ -148,6 +149,7 @@ struct intel_guc {
struct i915_vma *ads_vma;
/** @ads_blob: contents of the GuC ADS */
struct __guc_ads_blob *ads_blob;
+ struct iosys_map ads_map;
/** @ads_regset_size: size of the save/restore regsets in the ADS */
u32 ads_regset_size;
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 7e41175618f5..4ea842752bbc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -666,6 +666,11 @@ int intel_guc_ads_create(struct intel_guc *guc)
if (ret)
return ret;
+ if (i915_gem_object_is_lmem(guc->ads_vma->obj))
+ iosys_map_set_vaddr_iomem(&guc->ads_map, (void __iomem
*)guc->ads_blob);
+ else
+ iosys_map_set_vaddr(&guc->ads_map, guc->ads_blob);
+
__guc_ads_init(guc);
return 0;
@@ -687,6 +692,7 @@ void intel_guc_ads_destroy(struct intel_guc *guc)
{
i915_vma_unpin_and_release(&guc->ads_vma, I915_VMA_RELEASE_MAP);
guc->ads_blob = NULL;
+ iosys_map_clear(&guc->ads_map);
kfree(guc->ads_regset);
}
--
2.35.1
[Intel-gfx] [PATCH v3 05/16] drm/i915/guc: Add read/write helpers for ADS blob
Add helpers on top of iosys_map_read_field() /
iosys_map_write_field() functions so they always use the right
arguments and make code easier to read.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 4ea842752bbc..b645df7d46b6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -60,6 +60,13 @@ struct __guc_ads_blob {
struct guc_mmio_reg regset[0];
} __packed;
+#define ads_blob_read(guc_, field_)\
+ iosys_map_rd_field(&(guc_)->ads_map, 0, struct __guc_ads_blob, field_)
+
+#define ads_blob_write(guc_, field_, val_) \
+ iosys_map_wr_field(&(guc_)->ads_map, 0, struct __guc_ads_blob, \
+ field_, val_)
+
static u32 guc_ads_regset_size(struct intel_guc *guc)
{
GEM_BUG_ON(!guc->ads_regset_size);
--
2.35.1
[Intel-gfx] [PATCH v3 01/16] iosys-map: Add offset to iosys_map_memcpy_to()
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
Reviewed-by: Christian König
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_cache.c | 2 +-
drivers/gpu/drm/drm_fb_helper.c | 2 +-
include/linux/iosys-map.h | 17 +
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 66597e411764..c3e6e615bf09 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -218,7 +218,7 @@ static void memcpy_fallback(struct iosys_map *dst,
if (!dst->is_iomem && !src->is_iomem) {
memcpy(dst->vaddr, src->vaddr, len);
} else if (!src->is_iomem) {
- iosys_map_memcpy_to(dst, src->vaddr, len);
+ iosys_map_memcpy_to(dst, 0, src->vaddr, len);
} else if (!dst->is_iomem) {
memcpy_fromio(dst->vaddr, src->vaddr_iomem, len);
} else {
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 409d8dd7f868..d265a73313c9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -385,7 +385,7 @@ static void drm_fb_helper_damage_blit_real(struct
drm_fb_helper *fb_helper,
iosys_map_incr(dst, offset); /* go to first pixel within clip rect */
for (y = clip->y1; y < clip->y2; y++) {
- iosys_map_memcpy_to(dst, src, len);
+ iosys_map_memcpy_to(dst, 0, src, len);
iosys_map_incr(dst, fb->pitches[0]);
src += fb->pitches[0];
}
diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index f4186f91caa6..edd730b1e899 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -220,22 +220,23 @@ static inline void iosys_map_clear(struct iosys_map *map)
}
/**
- * iosys_map_memcpy_to - Memcpy into iosys mapping
+ * iosys_map_memcpy_to - Memcpy into offset of iosys_map
* @dst: The iosys_map structure
+ * @dst_offset:The offset from which to copy
* @src: The source buffer
* @len: The number of byte in src
*
- * Copies data into a iosys mapping. The source buffer is in system
- * memory. Depending on the buffer's location, the helper picks the correct
- * method of accessing the memory.
+ * Copies data into a iosys_map with an offset. The source buffer is in
+ * system memory. Depending on the buffer's location, the helper picks the
+ * correct method of accessing the memory.
*/
-static inline void iosys_map_memcpy_to(struct iosys_map *dst, const void *src,
- size_t len)
+static inline void iosys_map_memcpy_to(struct iosys_map *dst, size_t
dst_offset,
+ const void *src, size_t len)
{
if (dst->is_iomem)
- memcpy_toio(dst->vaddr_iomem, src, len);
+ memcpy_toio(dst->vaddr_iomem + dst_offset, src, len);
else
- memcpy(dst->vaddr, src, len);
+ memcpy(dst->vaddr + dst_offset, src, len);
}
/**
--
2.35.1
[Intel-gfx] [PATCH v3 03/16] drm/i915/gt: Add helper for shmem copy to iosys_map
Add a variant of shmem_read() that takes a iosys_map pointer rather
than a plain pointer as argument. It's mostly a copy __shmem_rw() but
adapting the api and removing the write support since there's currently
only need to use iosys_map as destination.
Reworking __shmem_rw() to share the implementation was tempting, but
finding a good balance between reuse and clarity pushed towards a little
code duplication. Since the function is small, just add the similar
function with a copy/paste/adapt approach.
v2: Add an offset as argument and instead of using a map iterator, use the
offset to keep track of where we are writing data to.
Cc: Matt Roper
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 32 +++
drivers/gpu/drm/i915/gt/shmem_utils.h | 3 +++
2 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 0683b27a3890..402f085f3a02 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -3,6 +3,7 @@
* Copyright © 2020 Intel Corporation
*/
+#include
#include
#include
#include
@@ -123,6 +124,37 @@ static int __shmem_rw(struct file *file, loff_t off,
return 0;
}
+int shmem_read_to_iosys_map(struct file *file, loff_t off,
+ struct iosys_map *map, size_t map_off, size_t len)
+{
+ unsigned long pfn;
+
+ for (pfn = off >> PAGE_SHIFT; len; pfn++) {
+ unsigned int this =
+ min_t(size_t, PAGE_SIZE - offset_in_page(off), len);
+ struct page *page;
+ void *vaddr;
+
+ page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
+ GFP_KERNEL);
+ if (IS_ERR(page))
+ return PTR_ERR(page);
+
+ vaddr = kmap(page);
+ iosys_map_memcpy_to(map, map_off, vaddr + offset_in_page(off),
+ this);
+ mark_page_accessed(page);
+ kunmap(page);
+ put_page(page);
+
+ len -= this;
+ map_off += this;
+ off = 0;
+ }
+
+ return 0;
+}
+
int shmem_read(struct file *file, loff_t off, void *dst, size_t len)
{
return __shmem_rw(file, off, dst, len, false);
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.h
b/drivers/gpu/drm/i915/gt/shmem_utils.h
index c1669170c351..b2b04d88c6e5 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.h
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.h
@@ -8,6 +8,7 @@
#include
+struct iosys_map;
struct drm_i915_gem_object;
struct file;
@@ -17,6 +18,8 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj);
void *shmem_pin_map(struct file *file);
void shmem_unpin_map(struct file *file, void *ptr);
+int shmem_read_to_iosys_map(struct file *file, loff_t off,
+ struct iosys_map *map, size_t map_off, size_t len);
int shmem_read(struct file *file, loff_t off, void *dst, size_t len);
int shmem_write(struct file *file, loff_t off, void *src, size_t len);
--
2.35.1
[Intel-gfx] [PATCH v3 10/16] drm/i915/guc: Convert golden context prep to iosys_map
Use the saved ads_map to prepare the golden context. One difference from
the init context is that this function can be called before there is a
gem object (and thus the guc->ads_map) to calculare the size of the
golden context that should be allocated for that object.
So in this case the function needs to be prepared for not having the
system_info with enabled engines filled out. To accomplish that an
info_map is prepared on the side to point either to the gem object
or the local variable on the stack. This allows making
fill_engine_enable_masks() operate always with a iosys_map
argument.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 52 +-
1 file changed, 32 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index d924486490c1..0077a63832ad 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -67,6 +67,12 @@ struct __guc_ads_blob {
iosys_map_wr_field(&(guc_)->ads_map, 0, struct __guc_ads_blob, \
field_, val_)
+#define info_map_write(map_, field_, val_) \
+ iosys_map_wr_field(map_, 0, struct guc_gt_system_info, field_, val_)
+
+#define info_map_read(map_, field_) \
+ iosys_map_rd_field(map_, 0, struct guc_gt_system_info, field_)
+
static u32 guc_ads_regset_size(struct intel_guc *guc)
{
GEM_BUG_ON(!guc->ads_regset_size);
@@ -417,24 +423,24 @@ static void guc_mmio_reg_state_init(struct intel_guc *guc,
}
static void fill_engine_enable_masks(struct intel_gt *gt,
-struct guc_gt_system_info *info)
+struct iosys_map *info_map)
{
- info->engine_enabled_masks[GUC_RENDER_CLASS] = 1;
- info->engine_enabled_masks[GUC_BLITTER_CLASS] = 1;
- info->engine_enabled_masks[GUC_VIDEO_CLASS] = VDBOX_MASK(gt);
- info->engine_enabled_masks[GUC_VIDEOENHANCE_CLASS] = VEBOX_MASK(gt);
+ info_map_write(info_map, engine_enabled_masks[GUC_RENDER_CLASS], 1);
+ info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS], 1);
+ info_map_write(info_map, engine_enabled_masks[GUC_VIDEO_CLASS],
VDBOX_MASK(gt));
+ info_map_write(info_map, engine_enabled_masks[GUC_VIDEOENHANCE_CLASS],
VEBOX_MASK(gt));
}
#define LR_HW_CONTEXT_SIZE (80 * sizeof(u32))
#define LRC_SKIP_SIZE (LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE)
-static int guc_prep_golden_context(struct intel_guc *guc,
- struct __guc_ads_blob *blob)
+static int guc_prep_golden_context(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
u32 addr_ggtt, offset;
u32 total_size = 0, alloc_size, real_size;
u8 engine_class, guc_class;
- struct guc_gt_system_info *info, local_info;
+ struct guc_gt_system_info local_info;
+ struct iosys_map info_map;
/*
* Reserve the memory for the golden contexts and point GuC at it but
@@ -448,14 +454,15 @@ static int guc_prep_golden_context(struct intel_guc *guc,
* GuC will also validate that the LRC base + size fall within the
* allowed GGTT range.
*/
- if (blob) {
+ if (!iosys_map_is_null(&guc->ads_map)) {
offset = guc_ads_golden_ctxt_offset(guc);
addr_ggtt = intel_guc_ggtt_offset(guc, guc->ads_vma) + offset;
- info = &blob->system_info;
+ info_map = IOSYS_MAP_INIT_OFFSET(&guc->ads_map,
+offsetof(struct
__guc_ads_blob, system_info));
} else {
memset(&local_info, 0, sizeof(local_info));
- info = &local_info;
- fill_engine_enable_masks(gt, info);
+ iosys_map_set_vaddr(&info_map, &local_info);
+ fill_engine_enable_masks(gt, &info_map);
}
for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
++engine_class) {
@@ -464,14 +471,14 @@ static int guc_prep_golden_context(struct intel_guc *guc,
guc_class = engine_class_to_guc_class(engine_class);
- if (!info->engine_enabled_masks[guc_class])
+ if (!info_map_read(&info_map, engine_enabled_masks[guc_class]))
continue;
real_size = intel_engine_context_size(gt, engine_class);
alloc_size = PAGE_ALIGN(real_size);
total_size += alloc_size;
- if (!blob)
+ if (iosys_map_is_null(&guc->ads_map))
continue;
/*
@@ -485,12 +492,15 @@ static int guc_prep_golden_context(struct intel_guc *guc,
* what comes before it in the context image (which is identical
[Intel-gfx] [PATCH v3 06/16] drm/i915/guc: Convert golden context init to iosys_map
Now the map is saved during creation, so use it to initialize the
golden context, reading from shmem and writing to either system or IO
memory.
v2: Do not use a map iterator: add an offset to keep track of
destination
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 26 ++
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index b645df7d46b6..5c52bee516cf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -512,18 +512,16 @@ static struct intel_engine_cs *find_engine_state(struct
intel_gt *gt, u8 engine_
static void guc_init_golden_context(struct intel_guc *guc)
{
- struct __guc_ads_blob *blob = guc->ads_blob;
struct intel_engine_cs *engine;
struct intel_gt *gt = guc_to_gt(guc);
- u32 addr_ggtt, offset;
- u32 total_size = 0, alloc_size, real_size;
+ unsigned long offset;
+ u32 addr_ggtt, total_size = 0, alloc_size, real_size;
u8 engine_class, guc_class;
- u8 *ptr;
if (!intel_uc_uses_guc_submission(>->uc))
return;
- GEM_BUG_ON(!blob);
+ GEM_BUG_ON(iosys_map_is_null(&guc->ads_map));
/*
* Go back and fill in the golden context data now that it is
@@ -531,15 +529,13 @@ static void guc_init_golden_context(struct intel_guc *guc)
*/
offset = guc_ads_golden_ctxt_offset(guc);
addr_ggtt = intel_guc_ggtt_offset(guc, guc->ads_vma) + offset;
- ptr = ((u8 *)blob) + offset;
for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
++engine_class) {
if (engine_class == OTHER_CLASS)
continue;
guc_class = engine_class_to_guc_class(engine_class);
-
- if (!blob->system_info.engine_enabled_masks[guc_class])
+ if (!ads_blob_read(guc,
system_info.engine_enabled_masks[guc_class]))
continue;
real_size = intel_engine_context_size(gt, engine_class);
@@ -550,18 +546,20 @@ static void guc_init_golden_context(struct intel_guc *guc)
if (!engine) {
drm_err(>->i915->drm, "No engine state recorded for
class %d!\n",
engine_class);
- blob->ads.eng_state_size[guc_class] = 0;
- blob->ads.golden_context_lrca[guc_class] = 0;
+ ads_blob_write(guc, ads.eng_state_size[guc_class], 0);
+ ads_blob_write(guc, ads.golden_context_lrca[guc_class],
0);
continue;
}
- GEM_BUG_ON(blob->ads.eng_state_size[guc_class] !=
+ GEM_BUG_ON(ads_blob_read(guc, ads.eng_state_size[guc_class]) !=
real_size - LRC_SKIP_SIZE);
- GEM_BUG_ON(blob->ads.golden_context_lrca[guc_class] !=
addr_ggtt);
+ GEM_BUG_ON(ads_blob_read(guc,
ads.golden_context_lrca[guc_class]) != addr_ggtt);
+
addr_ggtt += alloc_size;
- shmem_read(engine->default_state, 0, ptr, real_size);
- ptr += alloc_size;
+ shmem_read_to_iosys_map(engine->default_state, 0, &guc->ads_map,
+ offset, real_size);
+ offset += alloc_size;
}
GEM_BUG_ON(guc->ads_golden_ctxt_size != total_size);
--
2.35.1
[Intel-gfx] [PATCH v3 13/16] drm/i915/guc: Convert capture list to iosys_map
Use iosys_map to write the fields ads.capture_*.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index c3c31b679e79..ec0ccdf98dfa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -580,7 +580,7 @@ static void guc_init_golden_context(struct intel_guc *guc)
GEM_BUG_ON(guc->ads_golden_ctxt_size != total_size);
}
-static void guc_capture_list_init(struct intel_guc *guc, struct __guc_ads_blob
*blob)
+static void guc_capture_list_init(struct intel_guc *guc)
{
int i, j;
u32 addr_ggtt, offset;
@@ -592,11 +592,11 @@ static void guc_capture_list_init(struct intel_guc *guc,
struct __guc_ads_blob *
for (i = 0; i < GUC_CAPTURE_LIST_INDEX_MAX; i++) {
for (j = 0; j < GUC_MAX_ENGINE_CLASSES; j++) {
- blob->ads.capture_instance[i][j] = addr_ggtt;
- blob->ads.capture_class[i][j] = addr_ggtt;
+ ads_blob_write(guc, ads.capture_instance[i][j],
addr_ggtt);
+ ads_blob_write(guc, ads.capture_class[i][j], addr_ggtt);
}
- blob->ads.capture_global[i] = addr_ggtt;
+ ads_blob_write(guc, ads.capture_global[i], addr_ggtt);
}
}
@@ -636,7 +636,7 @@ static void __guc_ads_init(struct intel_guc *guc)
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
/* Capture list for hang debug */
- guc_capture_list_init(guc, blob);
+ guc_capture_list_init(guc);
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
--
2.35.1
[Intel-gfx] [PATCH v3 08/16] drm/i915/guc: Convert engine record to iosys_map
Use iosys_map to read fields from the dma_blob so access to IO and
system memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 14 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h | 3 ++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 ++---
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 7906a4df5a53..c61648ef3920 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -738,18 +738,16 @@ void intel_guc_ads_reset(struct intel_guc *guc)
u32 intel_guc_engine_usage_offset(struct intel_guc *guc)
{
- struct __guc_ads_blob *blob = guc->ads_blob;
- u32 base = intel_guc_ggtt_offset(guc, guc->ads_vma);
- u32 offset = base + ptr_offset(blob, engine_usage);
-
- return offset;
+ return intel_guc_ggtt_offset(guc, guc->ads_vma) +
+ offsetof(struct __guc_ads_blob, engine_usage);
}
-struct guc_engine_usage_record *intel_guc_engine_usage(struct intel_engine_cs
*engine)
+struct iosys_map intel_guc_engine_usage_record_map(struct intel_engine_cs
*engine)
{
struct intel_guc *guc = &engine->gt->uc.guc;
- struct __guc_ads_blob *blob = guc->ads_blob;
u8 guc_class = engine_class_to_guc_class(engine->class);
+ size_t offset = offsetof(struct __guc_ads_blob,
+
engine_usage.engines[guc_class][ilog2(engine->logical_mask)]);
- return
&blob->engine_usage.engines[guc_class][ilog2(engine->logical_mask)];
+ return IOSYS_MAP_INIT_OFFSET(&guc->ads_map, offset);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
index e74c110facff..1c64f4d6ea21 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
@@ -7,6 +7,7 @@
#define _INTEL_GUC_ADS_H_
#include
+#include
struct intel_guc;
struct drm_printer;
@@ -18,7 +19,7 @@ void intel_guc_ads_init_late(struct intel_guc *guc);
void intel_guc_ads_reset(struct intel_guc *guc);
void intel_guc_ads_print_policy_info(struct intel_guc *guc,
struct drm_printer *p);
-struct guc_engine_usage_record *intel_guc_engine_usage(struct intel_engine_cs
*engine);
+struct iosys_map intel_guc_engine_usage_record_map(struct intel_engine_cs
*engine);
u32 intel_guc_engine_usage_offset(struct intel_guc *guc);
#endif
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 b3a429a92c0d..ab3cea352fb3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1139,6 +1139,9 @@ __extend_last_switch(struct intel_guc *guc, u64
*prev_start, u32 new_start)
*prev_start = ((u64)gt_stamp_hi << 32) | new_start;
}
+#define record_read(map_, field_) \
+ iosys_map_rd_field(map_, 0, struct guc_engine_usage_record, field_)
+
/*
* GuC updates shared memory and KMD reads it. Since this is not synchronized,
* we run into a race where the value read is inconsistent. Sometimes the
@@ -1153,17 +1156,17 @@ __extend_last_switch(struct intel_guc *guc, u64
*prev_start, u32 new_start)
static void __get_engine_usage_record(struct intel_engine_cs *engine,
u32 *last_in, u32 *id, u32 *total)
{
- struct guc_engine_usage_record *rec = intel_guc_engine_usage(engine);
+ struct iosys_map rec_map = intel_guc_engine_usage_record_map(engine);
int i = 0;
do {
- *last_in = READ_ONCE(rec->last_switch_in_stamp);
- *id = READ_ONCE(rec->current_context_index);
- *total = READ_ONCE(rec->total_runtime);
+ *last_in = record_read(&rec_map, last_switch_in_stamp);
+ *id = record_read(&rec_map, current_context_index);
+ *total = record_read(&rec_map, total_runtime);
- if (READ_ONCE(rec->last_switch_in_stamp) == *last_in &&
- READ_ONCE(rec->current_context_index) == *id &&
- READ_ONCE(rec->total_runtime) == *total)
+ if (record_read(&rec_map, last_switch_in_stamp) == *last_in &&
+ record_read(&rec_map, current_context_index) == *id &&
+ record_read(&rec_map, total_runtime) == *total)
break;
} while (++i < 6);
}
--
2.35.1
[Intel-gfx] [PATCH v3 11/16] drm/i915/guc: Replace check for golden context size
In the other places in this function, guc->ads_map is being protected from access when it's not yet set. However the last check is actually about guc->ads_golden_ctxt_size been set before. These checks should always match as the size is initialized on the first call to guc_prep_golden_context(), but it's clearer if we have a single return and check for guc->ads_golden_ctxt_size. This is just a readability improvement, no change in behavior. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c index 0077a63832ad..b739781bd133 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c @@ -500,10 +500,10 @@ static int guc_prep_golden_context(struct intel_guc *guc) addr_ggtt += alloc_size; } - if (iosys_map_is_null(&guc->ads_map)) - return total_size; + /* Make sure current size matches what we calculated previously */ + if (guc->ads_golden_ctxt_size) + GEM_BUG_ON(guc->ads_golden_ctxt_size != total_size); - GEM_BUG_ON(guc->ads_golden_ctxt_size != total_size); return total_size; } -- 2.35.1
[Intel-gfx] [PATCH v3 07/16] drm/i915/guc: Convert policies update to iosys_map
Use iosys_map to write the policies update so access to IO and system
memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 41 --
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 5c52bee516cf..7906a4df5a53 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -130,33 +130,37 @@ static u32 guc_ads_blob_size(struct intel_guc *guc)
guc_ads_private_data_size(guc);
}
-static void guc_policies_init(struct intel_guc *guc, struct guc_policies
*policies)
+static void guc_policies_init(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
+ u32 global_flags = 0;
- policies->dpc_promote_time = GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
- policies->max_num_work_items = GLOBAL_POLICY_MAX_NUM_WI;
+ ads_blob_write(guc, policies.dpc_promote_time,
+ GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US);
+ ads_blob_write(guc, policies.max_num_work_items,
+ GLOBAL_POLICY_MAX_NUM_WI);
- policies->global_flags = 0;
if (i915->params.reset < 2)
- policies->global_flags |= GLOBAL_POLICY_DISABLE_ENGINE_RESET;
+ global_flags |= GLOBAL_POLICY_DISABLE_ENGINE_RESET;
- policies->is_valid = 1;
+ ads_blob_write(guc, policies.global_flags, global_flags);
+ ads_blob_write(guc, policies.is_valid, 1);
}
void intel_guc_ads_print_policy_info(struct intel_guc *guc,
struct drm_printer *dp)
{
- struct __guc_ads_blob *blob = guc->ads_blob;
-
- if (unlikely(!blob))
+ if (unlikely(iosys_map_is_null(&guc->ads_map)))
return;
drm_printf(dp, "Global scheduling policies:\n");
- drm_printf(dp, " DPC promote time = %u\n",
blob->policies.dpc_promote_time);
- drm_printf(dp, " Max num work items = %u\n",
blob->policies.max_num_work_items);
- drm_printf(dp, " Flags = %u\n",
blob->policies.global_flags);
+ drm_printf(dp, " DPC promote time = %u\n",
+ ads_blob_read(guc, policies.dpc_promote_time));
+ drm_printf(dp, " Max num work items = %u\n",
+ ads_blob_read(guc, policies.max_num_work_items));
+ drm_printf(dp, " Flags = %u\n",
+ ads_blob_read(guc, policies.global_flags));
}
static int guc_action_policies_update(struct intel_guc *guc, u32 policy_offset)
@@ -171,23 +175,24 @@ static int guc_action_policies_update(struct intel_guc
*guc, u32 policy_offset)
int intel_guc_global_policies_update(struct intel_guc *guc)
{
- struct __guc_ads_blob *blob = guc->ads_blob;
struct intel_gt *gt = guc_to_gt(guc);
+ u32 scheduler_policies;
intel_wakeref_t wakeref;
int ret;
- if (!blob)
+ if (iosys_map_is_null(&guc->ads_map))
return -EOPNOTSUPP;
- GEM_BUG_ON(!blob->ads.scheduler_policies);
+ scheduler_policies = ads_blob_read(guc, ads.scheduler_policies);
+ GEM_BUG_ON(!scheduler_policies);
- guc_policies_init(guc, &blob->policies);
+ guc_policies_init(guc);
if (!intel_guc_is_ready(guc))
return 0;
with_intel_runtime_pm(>->i915->runtime_pm, wakeref)
- ret = guc_action_policies_update(guc,
blob->ads.scheduler_policies);
+ ret = guc_action_policies_update(guc, scheduler_policies);
return ret;
}
@@ -593,7 +598,7 @@ static void __guc_ads_init(struct intel_guc *guc)
u32 base;
/* GuC scheduling policies */
- guc_policies_init(guc, &blob->policies);
+ guc_policies_init(guc);
/* System info */
fill_engine_enable_masks(gt, &blob->system_info);
--
2.35.1
[Intel-gfx] [PATCH v3 15/16] drm/i915/guc: Convert __guc_ads_init to iosys_map
Now that all the called functions from __guc_ads_init() are converted to
use ads_map, stop using ads_blob in __guc_ads_init().
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 25 --
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 90cbb93a2945..d0593063c0dc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -608,7 +608,6 @@ static void __guc_ads_init(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
struct drm_i915_private *i915 = gt->i915;
- struct __guc_ads_blob *blob = guc->ads_blob;
struct iosys_map info_map = IOSYS_MAP_INIT_OFFSET(&guc->ads_map,
offsetof(struct __guc_ads_blob, system_info));
u32 base;
@@ -619,17 +618,18 @@ static void __guc_ads_init(struct intel_guc *guc)
/* System info */
fill_engine_enable_masks(gt, &info_map);
-
blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_SLICE_ENABLED] =
- hweight8(gt->info.sseu.slice_mask);
-
blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_VDBOX_SFC_SUPPORT_MASK]
=
- gt->info.vdbox_sfc_access;
+ ads_blob_write(guc,
system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_SLICE_ENABLED],
+ hweight8(gt->info.sseu.slice_mask));
+ ads_blob_write(guc,
system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_VDBOX_SFC_SUPPORT_MASK],
+ gt->info.vdbox_sfc_access);
if (GRAPHICS_VER(i915) >= 12 && !IS_DGFX(i915)) {
u32 distdbreg = intel_uncore_read(gt->uncore,
GEN12_DIST_DBS_POPULATED);
-
blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_DOORBELL_COUNT_PER_SQIDI]
=
- ((distdbreg >> GEN12_DOORBELLS_PER_SQIDI_SHIFT) &
-GEN12_DOORBELLS_PER_SQIDI) + 1;
+ ads_blob_write(guc,
+
system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_DOORBELL_COUNT_PER_SQIDI],
+ ((distdbreg >> GEN12_DOORBELLS_PER_SQIDI_SHIFT)
+ & GEN12_DOORBELLS_PER_SQIDI) + 1);
}
/* Golden contexts for re-initialising after a watchdog reset */
@@ -643,14 +643,17 @@ static void __guc_ads_init(struct intel_guc *guc)
guc_capture_list_init(guc);
/* ADS */
- blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
- blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
+ ads_blob_write(guc, ads.scheduler_policies, base +
+ offsetof(struct __guc_ads_blob, policies));
+ ads_blob_write(guc, ads.gt_system_info, base +
+ offsetof(struct __guc_ads_blob, system_info));
/* MMIO save/restore list */
guc_mmio_reg_state_init(guc);
/* Private Data */
- blob->ads.private_data = base + guc_ads_private_data_offset(guc);
+ ads_blob_write(guc, ads.private_data, base +
+ guc_ads_private_data_offset(guc));
i915_gem_object_flush_map(guc->ads_vma->obj);
}
--
2.35.1
[Intel-gfx] [PATCH v3 09/16] drm/i915/guc: Convert guc_ads_private_data_reset to iosys_map
Use iosys_map_memset() to zero the private data as ADS may be either on system or IO memory. Cc: Matt Roper Cc: Thomas Hellström Cc: Daniel Vetter Cc: John Harrison Cc: Matthew Brost Cc: Daniele Ceraolo Spurio Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c index c61648ef3920..d924486490c1 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c @@ -714,8 +714,8 @@ static void guc_ads_private_data_reset(struct intel_guc *guc) if (!size) return; - memset((void *)guc->ads_blob + guc_ads_private_data_offset(guc), 0, - size); + iosys_map_memset(&guc->ads_map, guc_ads_private_data_offset(guc), +0, size); } /** -- 2.35.1
[Intel-gfx] [PATCH v3 02/16] iosys-map: Add a few more helpers
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
- iosys_map_memcpy_from(): we may need to copy data from I/O
memory, not only to.
In certain situations it's useful to be able to read or write to an
offset that is calculated by having the memory layout given by a struct
declaration. Usually we are going to read/write a u8, u16, u32 or u64.
As a pre-requisite for the implementation, add iosys_map_memcpy_from()
to be the equivalent of iosys_map_memcpy_to(), but in the other
direction. Then add 2 pairs of macros:
- iosys_map_rd() / iosys_map_wr()
- iosys_map_rd_field() / iosys_map_wr_field()
The first pair takes the C-type and offset to read/write. The second
pair uses a struct describing the layout of the mapping in order to
calculate the offset and size being read/written.
We could use readb, readw, readl, readq and the write* counterparts,
however due to alignment issues this may not work on all architectures.
If alignment needs to be checked to call the right function, it's not
possible to decide at compile-time which function to call: so just leave
the decision to the memcpy function that will do exactly that.
Finally, in order to use the above macros with a map derived from
another, add another initializer: IOSYS_MAP_INIT_OFFSET().
v2:
- Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules
within the union
- Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to
allow the struct itself to be at an offset from the mapping
- Add documentation to iosys_map_rd_field() with example and expected
memory layout
v3:
- Drop kernel.h include as it's not needed anymore
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: Mauro Carvalho Chehab
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
Reviewed-by: Mauro Carvalho Chehab
Reviewed-by: Matt Atwood
---
include/linux/iosys-map.h | 201 ++
1 file changed, 201 insertions(+)
diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index edd730b1e899..e69a002d5aa4 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -120,6 +120,45 @@ struct iosys_map {
.is_iomem = false, \
}
+/**
+ * IOSYS_MAP_INIT_OFFSET - Initializes struct iosys_map from another iosys_map
+ * @map_: The dma-buf mapping structure to copy from
+ * @offset_: Offset to add to the other mapping
+ *
+ * Initializes a new iosys_map struct based on another passed as argument. It
+ * does a shallow copy of the struct so it's possible to update the back
storage
+ * without changing where the original map points to. It is the equivalent of
+ * doing:
+ *
+ * .. code-block:: c
+ *
+ * iosys_map map = other_map;
+ * iosys_map_incr(&map, &offset);
+ *
+ * Example usage:
+ *
+ * .. code-block:: c
+ *
+ * void foo(struct device *dev, struct iosys_map *base_map)
+ * {
+ * ...
+ * struct iosys_map map = IOSYS_MAP_INIT_OFFSET(base_map,
FIELD_OFFSET);
+ * ...
+ * }
+ *
+ * The advantage of using the initializer over just increasing the offset with
+ * iosys_map_incr() like above is that the new map will always point to the
+ * right place of the buffer during its scope. It reduces the risk of updating
+ * the wrong part of the buffer and having no compiler warning about that. If
+ * the assignment to IOSYS_MAP_INIT_OFFSET() is forgotten, the compiler can
warn
+ * about the use of uninitialized variable.
+ */
+#define IOSYS_MAP_INIT_OFFSET(map_, offset_) ({
\
+ struct iosys_map copy = *map_; \
+ iosys_map_incr(©, offset_); \
+ copy; \
+})
+
/**
* iosys_map_set_vaddr - Sets a iosys mapping structure to an address in
system memory
* @map: The iosys_map structure
@@ -239,6 +278,26 @@ static inline void iosys_map_memcpy_to(struct iosys_map
*dst, size_t dst_offset,
memcpy(dst->vaddr + dst_offset, src, len);
}
+/**
+ * iosys_map_memcpy_from - Memcpy from iosys_map into system memory
+ * @dst: Destination in system memory
+ * @src: The iosys_map structure
+ * @src_offset:The offset from which to copy
+ * @len: The number of byte in src
+ *
+ * Copies data from a iosys_map with an offset. The dest buffer is in
+ * system memory. Depending on the mapping location, the helper picks the
+ * correct method of accessing the memory.
+ */
+static inline void iosys_map_memcpy_from(void *dst, const struct iosys_map
*src,
+size_t src_offset, size_t len)
+{
+ if (src->is_iomem)
+
[Intel-gfx] [PATCH v3 16/16] drm/i915/guc: Remove plain ads_blob pointer
Now we have the access to content of GuC ADS either using iosys_map
API or using a temporary buffer. Remove guc->ads_blob as there shouldn't
be updates using the bare pointer anymore.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 3 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 8
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index f857e9190750..bf7079480d47 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -147,8 +147,7 @@ struct intel_guc {
/** @ads_vma: object allocated to hold the GuC ADS */
struct i915_vma *ads_vma;
- /** @ads_blob: contents of the GuC ADS */
- struct __guc_ads_blob *ads_blob;
+ /** @ads_map: contents of the GuC ADS */
struct iosys_map ads_map;
/** @ads_regset_size: size of the save/restore regsets in the ADS */
u32 ads_regset_size;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index d0593063c0dc..847e00390b00 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -667,6 +667,7 @@ static void __guc_ads_init(struct intel_guc *guc)
*/
int intel_guc_ads_create(struct intel_guc *guc)
{
+ void *ads_blob;
u32 size;
int ret;
@@ -691,14 +692,14 @@ int intel_guc_ads_create(struct intel_guc *guc)
size = guc_ads_blob_size(guc);
ret = intel_guc_allocate_and_map_vma(guc, size, &guc->ads_vma,
-(void **)&guc->ads_blob);
+&ads_blob);
if (ret)
return ret;
if (i915_gem_object_is_lmem(guc->ads_vma->obj))
- iosys_map_set_vaddr_iomem(&guc->ads_map, (void __iomem
*)guc->ads_blob);
+ iosys_map_set_vaddr_iomem(&guc->ads_map, (void __iomem
*)ads_blob);
else
- iosys_map_set_vaddr(&guc->ads_map, guc->ads_blob);
+ iosys_map_set_vaddr(&guc->ads_map, ads_blob);
__guc_ads_init(guc);
@@ -720,7 +721,6 @@ void intel_guc_ads_init_late(struct intel_guc *guc)
void intel_guc_ads_destroy(struct intel_guc *guc)
{
i915_vma_unpin_and_release(&guc->ads_vma, I915_VMA_RELEASE_MAP);
- guc->ads_blob = NULL;
iosys_map_clear(&guc->ads_map);
kfree(guc->ads_regset);
}
--
2.35.1
[Intel-gfx] [PATCH v3 14/16] drm/i915/guc: Convert guc_mmio_reg_state_init to iosys_map
Now that the regset list is prepared, convert guc_mmio_reg_state_init()
to use iosys_map to copy the array to the final location and
initialize additional fields in ads.reg_state_list.
v2: Just use an offset instead of temporary iosys_map.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 28 --
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index ec0ccdf98dfa..90cbb93a2945 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -383,40 +383,44 @@ static long guc_mmio_reg_state_create(struct intel_guc
*guc)
return ret;
}
-static void guc_mmio_reg_state_init(struct intel_guc *guc,
- struct __guc_ads_blob *blob)
+static void guc_mmio_reg_state_init(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
struct intel_engine_cs *engine;
- struct guc_mmio_reg *ads_registers;
enum intel_engine_id id;
u32 addr_ggtt, offset;
offset = guc_ads_regset_offset(guc);
addr_ggtt = intel_guc_ggtt_offset(guc, guc->ads_vma) + offset;
- ads_registers = (struct guc_mmio_reg *)(((u8 *)blob) + offset);
- memcpy(ads_registers, guc->ads_regset, guc->ads_regset_size);
+ iosys_map_memcpy_to(&guc->ads_map, offset, guc->ads_regset,
+ guc->ads_regset_size);
for_each_engine(engine, gt, id) {
u32 count = guc->ads_regset_count[id];
- struct guc_mmio_reg_set *ads_reg_set;
u8 guc_class;
/* Class index is checked in class converter */
GEM_BUG_ON(engine->instance >= GUC_MAX_INSTANCES_PER_CLASS);
guc_class = engine_class_to_guc_class(engine->class);
- ads_reg_set =
&blob->ads.reg_state_list[guc_class][engine->instance];
if (!count) {
- ads_reg_set->address = 0;
- ads_reg_set->count = 0;
+ ads_blob_write(guc,
+
ads.reg_state_list[guc_class][engine->instance].address,
+ 0);
+ ads_blob_write(guc,
+
ads.reg_state_list[guc_class][engine->instance].count,
+ 0);
continue;
}
- ads_reg_set->address = addr_ggtt;
- ads_reg_set->count = count;
+ ads_blob_write(guc,
+
ads.reg_state_list[guc_class][engine->instance].address,
+ addr_ggtt);
+ ads_blob_write(guc,
+
ads.reg_state_list[guc_class][engine->instance].count,
+ count);
addr_ggtt += count * sizeof(struct guc_mmio_reg);
}
@@ -643,7 +647,7 @@ static void __guc_ads_init(struct intel_guc *guc)
blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
/* MMIO save/restore list */
- guc_mmio_reg_state_init(guc, blob);
+ guc_mmio_reg_state_init(guc);
/* Private Data */
blob->ads.private_data = base + guc_ads_private_data_offset(guc);
--
2.35.1
[Intel-gfx] [PATCH v3 12/16] drm/i915/guc: Convert mapping table to iosys_map
Use iosys_map to write the fields system_info.mapping_table[][].
Since we already have the info_map around where needed, just use it
instead of going through guc->ads_map.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index b739781bd133..c3c31b679e79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -204,7 +204,7 @@ int intel_guc_global_policies_update(struct intel_guc *guc)
}
static void guc_mapping_table_init(struct intel_gt *gt,
- struct guc_gt_system_info *system_info)
+ struct iosys_map *info_map)
{
unsigned int i, j;
struct intel_engine_cs *engine;
@@ -213,14 +213,14 @@ static void guc_mapping_table_init(struct intel_gt *gt,
/* Table must be set to invalid values for entries not used */
for (i = 0; i < GUC_MAX_ENGINE_CLASSES; ++i)
for (j = 0; j < GUC_MAX_INSTANCES_PER_CLASS; ++j)
- system_info->mapping_table[i][j] =
- GUC_MAX_INSTANCES_PER_CLASS;
+ info_map_write(info_map, mapping_table[i][j],
+ GUC_MAX_INSTANCES_PER_CLASS);
for_each_engine(engine, gt, id) {
u8 guc_class = engine_class_to_guc_class(engine->class);
-
system_info->mapping_table[guc_class][ilog2(engine->logical_mask)] =
- engine->instance;
+ info_map_write(info_map,
mapping_table[guc_class][ilog2(engine->logical_mask)],
+ engine->instance);
}
}
@@ -631,7 +631,7 @@ static void __guc_ads_init(struct intel_guc *guc)
/* Golden contexts for re-initialising after a watchdog reset */
guc_prep_golden_context(guc);
- guc_mapping_table_init(guc_to_gt(guc), &blob->system_info);
+ guc_mapping_table_init(guc_to_gt(guc), &info_map);
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
--
2.35.1
[Intel-gfx] [PATCH v2 0/6] drm/i915: SAGV fixes
From: Ville Syrjälä While pokingaround the watermarks/etc. I noticed our SAGV code has a bunch of bugs. Let's try to fix it. Pushed a few patches from v1 already. And based on the discussion with Stan I added a few extra refactoring patches to the end in the hopes of making the logic less confusing. I still prefer the oneliner for the immediate bugfix in patch 2 so that we don't have to backport the refactoring as well. Cc: Stanislav Lisovskiy Ville Syrjälä (6): drm/i915: Correctly populate use_sagv_wm for all pipes drm/i915: Fix bw atomic check when switching between SAGV vs. no SAGV drm/i915: Split pre-icl vs. icl+ SAGV hooks apart drm/i915: Pimp icl+ sagv pre/post update drm/i915: Extract icl_qgv_points_mask() drm/i915: Extract intel_bw_check_data_rate() drivers/gpu/drm/i915/display/intel_bw.c | 71 +++--- drivers/gpu/drm/i915/intel_pm.c | 177 ++-- 2 files changed, 154 insertions(+), 94 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH v2 1/6] drm/i915: Correctly populate use_sagv_wm for all pipes
From: Ville Syrjälä
When changing between SAGV vs. no SAGV on tgl+ we have to
update the use_sagv_wm flag for all the crtcs or else
an active pipe not already in the state will end up using
the wrong watermarks. That is especially bad when we end up
with the tighter non-SAGV watermarks with SAGV enabled.
Usually ends up in underruns.
Cc: sta...@vger.kernel.org
Reviewed-by: Stanislav Lisovskiy
Fixes: 7241c57d3140 ("drm/i915: Add TGL+ SAGV support")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9f5e3c399f8d..bd32fd70e6b2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4007,6 +4007,17 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
return ret;
}
+ if (intel_can_enable_sagv(dev_priv, new_bw_state) !=
+ intel_can_enable_sagv(dev_priv, old_bw_state)) {
+ ret = intel_atomic_serialize_global_state(&new_bw_state->base);
+ if (ret)
+ return ret;
+ } else if (new_bw_state->pipe_sagv_reject !=
old_bw_state->pipe_sagv_reject) {
+ ret = intel_atomic_lock_global_state(&new_bw_state->base);
+ if (ret)
+ return ret;
+ }
+
for_each_new_intel_crtc_in_state(state, crtc,
new_crtc_state, i) {
struct skl_pipe_wm *pipe_wm = &new_crtc_state->wm.skl.optimal;
@@ -4022,17 +4033,6 @@ static int intel_compute_sagv_mask(struct
intel_atomic_state *state)
intel_can_enable_sagv(dev_priv, new_bw_state);
}
- if (intel_can_enable_sagv(dev_priv, new_bw_state) !=
- intel_can_enable_sagv(dev_priv, old_bw_state)) {
- ret = intel_atomic_serialize_global_state(&new_bw_state->base);
- if (ret)
- return ret;
- } else if (new_bw_state->pipe_sagv_reject !=
old_bw_state->pipe_sagv_reject) {
- ret = intel_atomic_lock_global_state(&new_bw_state->base);
- if (ret)
- return ret;
- }
-
return 0;
}
--
2.34.1
[Intel-gfx] [PATCH v2 2/6] drm/i915: Fix bw atomic check when switching between SAGV vs. no SAGV
From: Ville Syrjälä
If the only thing that is changing is SAGV vs. no SAGV but
the number of active planes and the total data rates end up
unchanged we currently bail out of intel_bw_atomic_check()
early and forget to actually compute the new WGV point
mask and thus won't actually enable/disable SAGV as requested.
This ends up poorly if we end up running with SAGV enabled
when we shouldn't. Usually ends up in underruns.
To fix this let's go through the QGV point mask computation
if anyone else already added the bw state for us.
Cc: sta...@vger.kernel.org
Cc: Stanislav Lisovskiy
Fixes: 20f505f22531 ("drm/i915: Restrict qgv points which don't have enough
bandwidth.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bw.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 23aa8e06de18..d72ccee7d53b 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -846,6 +846,13 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
if (num_psf_gv_points > 0)
mask |= REG_GENMASK(num_psf_gv_points - 1, 0) <<
ADLS_PSF_PT_SHIFT;
+ /*
+* If we already have the bw state then recompute everything
+* even if pipe data_rate / active_planes didn't change.
+* Other things (such as SAGV) may have changed.
+*/
+ new_bw_state = intel_atomic_get_new_bw_state(state);
+
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
unsigned int old_data_rate =
--
2.34.1
[Intel-gfx] [PATCH v2 3/6] drm/i915: Split pre-icl vs. icl+ SAGV hooks apart
From: Ville Syrjälä
To further reduce the confusion between the pre-icl vs. icl+
SAGV codepaths let's do a full split.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 120
1 file changed, 77 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bd32fd70e6b2..9e2c339f8d16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3781,34 +3781,44 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
return 0;
}
-void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
+static void skl_sagv_pre_plane_update(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+ const struct intel_bw_state *new_bw_state =
+ intel_atomic_get_new_bw_state(state);
+
+ if (!new_bw_state)
+ return;
+
+ if (!intel_can_enable_sagv(i915, new_bw_state))
+ intel_disable_sagv(i915);
+}
+
+static void skl_sagv_post_plane_update(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+ const struct intel_bw_state *new_bw_state =
+ intel_atomic_get_new_bw_state(state);
+
+ if (!new_bw_state)
+ return;
+
+ if (intel_can_enable_sagv(i915, new_bw_state))
+ intel_enable_sagv(i915);
+}
+
+static void icl_sagv_pre_plane_update(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- const struct intel_bw_state *new_bw_state;
- const struct intel_bw_state *old_bw_state;
- u32 new_mask = 0;
+ const struct intel_bw_state *old_bw_state =
+ intel_atomic_get_old_bw_state(state);
+ const struct intel_bw_state *new_bw_state =
+ intel_atomic_get_new_bw_state(state);
+ u32 new_mask;
- /*
-* Just return if we can't control SAGV or don't have it.
-* This is different from situation when we have SAGV but just can't
-* afford it due to DBuf limitation - in case if SAGV is completely
-* disabled in a BIOS, we are not even allowed to send a PCode request,
-* as it will throw an error. So have to check it here.
-*/
- if (!intel_has_sagv(dev_priv))
- return;
-
- new_bw_state = intel_atomic_get_new_bw_state(state);
if (!new_bw_state)
return;
- if (DISPLAY_VER(dev_priv) < 11) {
- if (!intel_can_enable_sagv(dev_priv, new_bw_state))
- intel_disable_sagv(dev_priv);
- return;
- }
-
- old_bw_state = intel_atomic_get_old_bw_state(state);
/*
* Nothing to mask
*/
@@ -3833,34 +3843,18 @@ void intel_sagv_pre_plane_update(struct
intel_atomic_state *state)
icl_pcode_restrict_qgv_points(dev_priv, new_mask);
}
-void intel_sagv_post_plane_update(struct intel_atomic_state *state)
+static void icl_sagv_post_plane_update(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- const struct intel_bw_state *new_bw_state;
- const struct intel_bw_state *old_bw_state;
+ const struct intel_bw_state *old_bw_state =
+ intel_atomic_get_old_bw_state(state);
+ const struct intel_bw_state *new_bw_state =
+ intel_atomic_get_new_bw_state(state);
u32 new_mask = 0;
- /*
-* Just return if we can't control SAGV or don't have it.
-* This is different from situation when we have SAGV but just can't
-* afford it due to DBuf limitation - in case if SAGV is completely
-* disabled in a BIOS, we are not even allowed to send a PCode request,
-* as it will throw an error. So have to check it here.
-*/
- if (!intel_has_sagv(dev_priv))
- return;
-
- new_bw_state = intel_atomic_get_new_bw_state(state);
if (!new_bw_state)
return;
- if (DISPLAY_VER(dev_priv) < 11) {
- if (intel_can_enable_sagv(dev_priv, new_bw_state))
- intel_enable_sagv(dev_priv);
- return;
- }
-
- old_bw_state = intel_atomic_get_old_bw_state(state);
/*
* Nothing to unmask
*/
@@ -3878,6 +3872,46 @@ void intel_sagv_post_plane_update(struct
intel_atomic_state *state)
icl_pcode_restrict_qgv_points(dev_priv, new_mask);
}
+void intel_sagv_pre_plane_update(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+
+ /*
+* Just return if we can't control SAGV or don't have it.
+* This is different from situation when we have SAGV but just can't
+* afford it due to DBuf limitation - in case if SAGV is completely
+* disable
[Intel-gfx] [PATCH v2 4/6] drm/i915: Pimp icl+ sagv pre/post update
From: Ville Syrjälä Add some debugs on what exactly we're doing to the QGV point mask in the icl+ sagv pre/post plane update hooks. Currently we're just guessing. v2: s/u32/u16/ for consistency with the mask sizes (Stan) Reviewed-by: Stanislav Lisovskiy Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 37 - 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 9e2c339f8d16..f4324c0326cd 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3814,26 +3814,22 @@ static void icl_sagv_pre_plane_update(struct intel_atomic_state *state) intel_atomic_get_old_bw_state(state); const struct intel_bw_state *new_bw_state = intel_atomic_get_new_bw_state(state); - u32 new_mask; + u16 old_mask, new_mask; if (!new_bw_state) return; - /* -* Nothing to mask -*/ - if (new_bw_state->qgv_points_mask == old_bw_state->qgv_points_mask) - return; - + old_mask = old_bw_state->qgv_points_mask; new_mask = old_bw_state->qgv_points_mask | new_bw_state->qgv_points_mask; - /* -* If new mask is zero - means there is nothing to mask, -* we can only unmask, which should be done in unmask. -*/ - if (!new_mask) + if (old_mask == new_mask) return; + WARN_ON(!new_bw_state->base.changed); + + drm_dbg_kms(&dev_priv->drm, "Restricting QGV points: 0x%x -> 0x%x\n", + old_mask, new_mask); + /* * Restrict required qgv points before updating the configuration. * According to BSpec we can't mask and unmask qgv points at the same @@ -3850,19 +3846,22 @@ static void icl_sagv_post_plane_update(struct intel_atomic_state *state) intel_atomic_get_old_bw_state(state); const struct intel_bw_state *new_bw_state = intel_atomic_get_new_bw_state(state); - u32 new_mask = 0; + u16 old_mask, new_mask; if (!new_bw_state) return; - /* -* Nothing to unmask -*/ - if (new_bw_state->qgv_points_mask == old_bw_state->qgv_points_mask) - return; - + old_mask = old_bw_state->qgv_points_mask | new_bw_state->qgv_points_mask; new_mask = new_bw_state->qgv_points_mask; + if (old_mask == new_mask) + return; + + WARN_ON(!new_bw_state->base.changed); + + drm_dbg_kms(&dev_priv->drm, "Relaxing QGV points: 0x%x -> 0x%x\n", + old_mask, new_mask); + /* * Allow required qgv points after updating the configuration. * According to BSpec we can't mask and unmask qgv points at the same -- 2.34.1
[Intel-gfx] [PATCH v2 5/6] drm/i915: Extract icl_qgv_points_mask()
From: Ville Syrjälä
Declutter intel_bw_atomic_check() a bit by pulling
the max QGV mask calculation out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bw.c | 35 -
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index d72ccee7d53b..fa03f0935b6d 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -815,6 +815,26 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state
*state)
return 0;
}
+static u16 icl_qgv_points_mask(struct drm_i915_private *i915)
+{
+ unsigned int num_psf_gv_points = i915->max_bw[0].num_psf_gv_points;
+ unsigned int num_qgv_points = i915->max_bw[0].num_qgv_points;
+ u16 mask = 0;
+
+ /*
+* We can _not_ use the whole ADLS_QGV_PT_MASK here, as PCode rejects
+* it with failure if we try masking any unadvertised points.
+* So need to operate only with those returned from PCode.
+*/
+ if (num_qgv_points > 0)
+ mask |= REG_GENMASK(num_qgv_points - 1, 0);
+
+ if (num_psf_gv_points > 0)
+ mask |= REG_GENMASK(num_psf_gv_points - 1, 0) <<
ADLS_PSF_PT_SHIFT;
+
+ return mask;
+}
+
int intel_bw_atomic_check(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
@@ -829,23 +849,11 @@ int intel_bw_atomic_check(struct intel_atomic_state
*state)
unsigned int max_bw_point = 0, max_bw = 0;
unsigned int num_qgv_points = dev_priv->max_bw[0].num_qgv_points;
unsigned int num_psf_gv_points = dev_priv->max_bw[0].num_psf_gv_points;
- u32 mask = 0;
/* FIXME earlier gens need some checks too */
if (DISPLAY_VER(dev_priv) < 11)
return 0;
- /*
-* We can _not_ use the whole ADLS_QGV_PT_MASK here, as PCode rejects
-* it with failure if we try masking any unadvertised points.
-* So need to operate only with those returned from PCode.
-*/
- if (num_qgv_points > 0)
- mask |= REG_GENMASK(num_qgv_points - 1, 0);
-
- if (num_psf_gv_points > 0)
- mask |= REG_GENMASK(num_psf_gv_points - 1, 0) <<
ADLS_PSF_PT_SHIFT;
-
/*
* If we already have the bw state then recompute everything
* even if pipe data_rate / active_planes didn't change.
@@ -970,7 +978,8 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
* We store the ones which need to be masked as that is what PCode
* actually accepts as a parameter.
*/
- new_bw_state->qgv_points_mask = ~allowed_points & mask;
+ new_bw_state->qgv_points_mask = ~allowed_points &
+ icl_qgv_points_mask(dev_priv);
old_bw_state = intel_atomic_get_old_bw_state(state);
/*
--
2.34.1
[Intel-gfx] [PATCH v2 6/6] drm/i915: Extract intel_bw_check_data_rate()
From: Ville Syrjälä
Extract the data rate calculation loop out from
intel_bw_atomic_check() to make it a bit less confusing.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bw.c | 63 +++--
1 file changed, 37 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index fa03f0935b6d..963b99d3557c 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -835,31 +835,12 @@ static u16 icl_qgv_points_mask(struct drm_i915_private
*i915)
return mask;
}
-int intel_bw_atomic_check(struct intel_atomic_state *state)
+static int intel_bw_check_data_rate(struct intel_atomic_state *state)
{
- struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- struct intel_crtc_state *new_crtc_state, *old_crtc_state;
- struct intel_bw_state *new_bw_state = NULL;
- const struct intel_bw_state *old_bw_state = NULL;
- unsigned int data_rate;
- unsigned int num_active_planes;
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+ const struct intel_crtc_state *new_crtc_state, *old_crtc_state;
struct intel_crtc *crtc;
- int i, ret;
- u32 allowed_points = 0;
- unsigned int max_bw_point = 0, max_bw = 0;
- unsigned int num_qgv_points = dev_priv->max_bw[0].num_qgv_points;
- unsigned int num_psf_gv_points = dev_priv->max_bw[0].num_psf_gv_points;
-
- /* FIXME earlier gens need some checks too */
- if (DISPLAY_VER(dev_priv) < 11)
- return 0;
-
- /*
-* If we already have the bw state then recompute everything
-* even if pipe data_rate / active_planes didn't change.
-* Other things (such as SAGV) may have changed.
-*/
- new_bw_state = intel_atomic_get_new_bw_state(state);
+ int i;
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -871,6 +852,7 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
intel_bw_crtc_num_active_planes(old_crtc_state);
unsigned int new_active_planes =
intel_bw_crtc_num_active_planes(new_crtc_state);
+ struct intel_bw_state *new_bw_state;
/*
* Avoid locking the bw state when
@@ -887,13 +869,42 @@ int intel_bw_atomic_check(struct intel_atomic_state
*state)
new_bw_state->data_rate[crtc->pipe] = new_data_rate;
new_bw_state->num_active_planes[crtc->pipe] = new_active_planes;
- drm_dbg_kms(&dev_priv->drm,
- "pipe %c data rate %u num active planes %u\n",
- pipe_name(crtc->pipe),
+ drm_dbg_kms(&i915->drm,
+ "[CRTC:%d:%s] data rate %u num active planes %u\n",
+ crtc->base.base.id, crtc->base.name,
new_bw_state->data_rate[crtc->pipe],
new_bw_state->num_active_planes[crtc->pipe]);
}
+ return 0;
+}
+
+int intel_bw_atomic_check(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ const struct intel_bw_state *old_bw_state;
+ struct intel_bw_state *new_bw_state;
+ unsigned int data_rate;
+ unsigned int num_active_planes;
+ int i, ret;
+ u32 allowed_points = 0;
+ unsigned int max_bw_point = 0, max_bw = 0;
+ unsigned int num_qgv_points = dev_priv->max_bw[0].num_qgv_points;
+ unsigned int num_psf_gv_points = dev_priv->max_bw[0].num_psf_gv_points;
+
+ /* FIXME earlier gens need some checks too */
+ if (DISPLAY_VER(dev_priv) < 11)
+ return 0;
+
+ ret = intel_bw_check_data_rate(state);
+ if (ret)
+ return ret;
+
+ /*
+* If we don't have a bw_state by now then none of the
+* inputs to the QGV mask computation may have changed.
+*/
+ new_bw_state = intel_atomic_get_new_bw_state(state);
if (!new_bw_state)
return 0;
--
2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: #include drm_edid.h for drm_edid_block_valid()
== Series Details ==
Series: drm/i915/gvt: #include drm_edid.h for drm_edid_block_valid()
URL : https://patchwork.freedesktop.org/series/100169/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11236 -> Patchwork_22281
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/index.html
Participating hosts (47 -> 41)
--
Missing(6): shard-tglu fi-bsw-cyan fi-kbl-7500u fi-kbl-8809g fi-pnv-d510
bat-rpls-2
Known issues
Here are the changes found in Patchwork_22281 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: NOTRUN -> [DMESG-FAIL][3] ([i915#4494] / [i915#4957])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][6] -> [INCOMPLETE][7] ([i915#3921])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271]) +21 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][11] ([fdo#109271] / [i915#1436] /
[i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [INCOMPLETE][12] ([i915#4547]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@i915_selftest@live@evict:
- fi-kbl-soraka: [DMESG-WARN][14] ([i915#4391]) -> [PASS][15] +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/fi-kbl-soraka/igt@i915_selftest@l...@evict.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [INCOMPLETE][16] ([i915#4418]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][18] ([i915#4957]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22281/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4312]: https://gitlab.freedesktop.or
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/fbdev: add intel_fbdev_framebuffer() helper
== Series Details == Series: series starting with [v2,1/2] drm/i915/fbdev: add intel_fbdev_framebuffer() helper URL : https://patchwork.freedesktop.org/series/100170/ State : warning == Summary == $ dim checkpatch origin/drm-tip b96b00c05a02 drm/i915/fbdev: add intel_fbdev_framebuffer() helper -:81: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #81: FILE: drivers/gpu/drm/i915/display/intel_fbdev.h:54: } +static inline struct intel_framebuffer *intel_fbdev_framebuffer(struct intel_fbdev *fbdev) total: 0 errors, 0 warnings, 1 checks, 54 lines checked 1bdb72ef0401 drm/i915/fbdev: hide struct intel_fbdev in intel_fbdev.c
[Intel-gfx] [PATCH] drm/i915/guc/slpc: Correct the param count for unset param
SLPC unset param H2G only needs one parameter - the id of the
param.
Fixes: 025cb07bebfa ("drm/i915/guc/slpc: Cache platform frequency limits")
Suggested-by: Umesh Nerlige Ramappa
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 13b27b8ff74e..ba21ace973da 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -110,7 +110,7 @@ static int guc_action_slpc_unset_param(struct intel_guc
*guc, u8 id)
{
u32 request[] = {
GUC_ACTION_HOST2GUC_PC_SLPC_REQUEST,
- SLPC_EVENT(SLPC_EVENT_PARAMETER_UNSET, 2),
+ SLPC_EVENT(SLPC_EVENT_PARAMETER_UNSET, 1),
id,
};
--
2.34.0
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/fbdev: add intel_fbdev_framebuffer() helper
== Series Details == Series: series starting with [v2,1/2] drm/i915/fbdev: add intel_fbdev_framebuffer() helper URL : https://patchwork.freedesktop.org/series/100170/ State : success == Summary == CI Bug Log - changes from CI_DRM_11236 -> Patchwork_22282 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/index.html Participating hosts (47 -> 37) -- Missing(10): shard-tglu bat-dg1-6 bat-dg1-5 bat-dg2-8 fi-bsw-cyan bat-adlp-6 bat-rpls-1 bat-rpls-2 bat-jsl-2 bat-jsl-1 Known issues Here are the changes found in Patchwork_22282 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#533]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: NOTRUN -> [FAIL][6] ([i915#4547]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@runner@aborted: - fi-skl-6600u: NOTRUN -> [FAIL][7] ([i915#4312]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-skl-6600u/igt@run...@aborted.html - fi-bdw-5557u: NOTRUN -> [FAIL][8] ([i915#2426] / [i915#4312]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: [INCOMPLETE][9] ([i915#4547]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@i915_selftest@live@evict: - fi-kbl-soraka: [DMESG-WARN][11] ([i915#4391]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-kbl-soraka/igt@i915_selftest@l...@evict.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/fi-kbl-soraka/igt@i915_selftest@l...@evict.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Build changes - * Linux: CI_DRM_11236 -> Patchwork_22282 CI-20190529: 20190529 CI_DRM_11236: a31966ca7e144f49f3ee98026e050b63365ba32a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6347: 37ea4c86f97c0e05fcb6b04cff72ec927930536e @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22282: 1bdb72ef04019f8ed93f771e95898ad84265097c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1bdb72ef0401 drm/i915/fbdev: hide struct intel_fbdev in intel_fbdev.c b96b00c05a02 drm/i915/fbdev: add intel_fbdev_framebuffer() helper == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22282/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DGFX OpRegion (rev2)
== Series Details ==
Series: DGFX OpRegion (rev2)
URL : https://patchwork.freedesktop.org/series/99738/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6d79d75ff620 drm/i915/opregion: Add intel_opregion_init() wrapper
768f0a166cf5 drm/i915/opregion: Abstract opregion function
-:209: ERROR:SPACING: space required before the open parenthesis '('
#209: FILE: drivers/gpu/drm/i915/display/intel_opregion.c:1265:
+ if(drm_WARN_ON(&i915->drm, !opregion->asls || !opregion->header))
total: 1 errors, 0 warnings, 0 checks, 254 lines checked
80d5f4ca4fd8 drm/i915/opregion: Add dgfx opregion func
f687dde9115c drm/i915/opregion: Cond dgfx opregion func registration
526152d056f6 drm/i915/dgfx: OPROM OpRegion Setup
-:229: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kzalloc(sizeof(*exprom_hdr)...) over
kzalloc(sizeof(struct expansion_rom_header)...)
#229: FILE: drivers/gpu/drm/i915/display/intel_opregion.c:1046:
+ exprom_hdr = kzalloc(sizeof(struct expansion_rom_header), GFP_KERNEL);
-:230: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kzalloc(sizeof(*exprom_pci_data)...)
over kzalloc(sizeof(struct pci_data_structure)...)
#230: FILE: drivers/gpu/drm/i915/display/intel_opregion.c:1047:
+ exprom_pci_data = kzalloc(sizeof(struct pci_data_structure),
GFP_KERNEL);
total: 0 errors, 0 warnings, 2 checks, 417 lines checked
5cb086bbc22d drm/i915/dgfx: Get VBT from rvda
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DGFX OpRegion (rev2)
== Series Details == Series: DGFX OpRegion (rev2) URL : https://patchwork.freedesktop.org/series/99738/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members
On Tue, Feb 15, 2022 at 8:24 PM Gustavo A. R. Silva wrote: > > On Tue, Feb 15, 2022 at 09:19:29PM +0200, Leon Romanovsky wrote: > > On Tue, Feb 15, 2022 at 01:21:10PM -0600, Gustavo A. R. Silva wrote: > > > On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote: > > > > On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote: > > > > > > > > These all look trivially correct to me. Only two didn't have the end of > > > > the struct visible in the patch, and checking those showed them to be > > > > trailing members as well, so: > > > > > > > > Reviewed-by: Kees Cook > > > > > > I'll add this to my -next tree. > > > > I would like to ask you to send mlx5 patch separately to netdev. We are > > working > > to delete that file completely and prefer to avoid from unnecessary merge > > conflicts. > > Oh OK. Sure thing; I will do so. Can you also send the ACPI patch separately, please? We would like to route it through the upstream ACPICA code base.
[Intel-gfx] ✓ Fi.CI.BAT: success for DGFX OpRegion (rev2)
== Series Details == Series: DGFX OpRegion (rev2) URL : https://patchwork.freedesktop.org/series/99738/ State : success == Summary == CI Bug Log - changes from CI_DRM_11236 -> Patchwork_22283 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/index.html Participating hosts (47 -> 44) -- Additional (1): fi-icl-u2 Missing(4): fi-bsw-cyan bat-rpls-1 shard-tglu fi-pnv-d510 Known issues Here are the changes found in Patchwork_22283 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-gfx0: - fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html - fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][6] ([i915#4957]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - fi-hsw-4770:[PASS][7] -> [INCOMPLETE][8] ([i915#3303]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html - fi-snb-2600:[PASS][9] -> [INCOMPLETE][10] ([i915#3921]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109278]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-skl-6600u: NOTRUN -> [SKIP][14] ([fdo#109271]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#109285]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-cfl-8109u: [PASS][17] -> [DMESG-WARN][18] ([i915#295]) +12 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11236/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: NOTRUN -> [INCOMPLETE][19] ([i915#4838]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@prime_vgem@basic-userptr: - fi-icl-u2: NOTRUN -> [SKIP][20] ([i915#3301]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22283/fi-icl-u2/igt@pr
Re: [Intel-gfx] [PATCH 01/12] drm/i915: Fix cursor coordinates on bigjoiner slave
On Wed, Feb 16, 2022 at 10:39:56AM +0200, Ville Syrjälä wrote: > On Tue, Feb 15, 2022 at 07:25:36PM -0800, Navare, Manasi wrote: > > On Tue, Feb 15, 2022 at 08:31:57PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Adjust the cursor dst coordinates appripriately when it's on > > > the bigjoiner slave pipe. intel_atomic_plane_check_clipping() > > > already did this but with the cursor we discard those results > > > (apart from uapi.visible and error checks) since the hardware > > > will be doing the clipping for us. > > > > > > v2: Rebase due to bigjoiner bitmask usage > > > > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/display/intel_cursor.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c > > > b/drivers/gpu/drm/i915/display/intel_cursor.c > > > index 2ade8fdd9bdd..3e80763aa828 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_cursor.c > > > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c > > > @@ -152,6 +152,9 @@ static int intel_check_cursor(struct intel_crtc_state > > > *crtc_state, > > > /* Use the unclipped src/dst rectangles, which we program to hw */ > > > plane_state->uapi.src = src; > > > plane_state->uapi.dst = dst; > > > + if (intel_crtc_is_bigjoiner_slave(crtc_state)) > > > + drm_rect_translate(&plane_state->uapi.dst, > > > +-crtc_state->pipe_src_w, 0); > > > > So this is basically to offset the cursor position from say 3860 to 0, 3861 > > to 1 7680 to 3860 for the right half > > of the screen right? > > And without this, it will just keep it at first rectangle? > > Yes. The original rectangle came from userspace and is thus > relative to the whole area covered by all the joined pipes. > But the plane coordinates we hand to the hardware must be > relative to their respective pipe. > > It's a bit ugly as is but works for now. The last patch make > this much nicer by removing all the assumptions here about > the relative positions of the pipes. Okay yes makes sens, Reviewed-by: Manasi Navare Manasi > > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Rename variables in intel_crtc_compute_config()
On Tue, Feb 15, 2022 at 08:31:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Do the s/dev_priv/i915/ and s/pipe_config/crtc_state/ renames
> to intel_crtc_compute_config(). I want to start splitting this
> up a bit and doing the renames now avoids spreading these old
> nameing conventions elsewhere.
>
> Signed-off-by: Ville Syrjälä
Yes the name cleanup looks good, would be good to call out "No functional
changes" in the
commit message.
With that
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 50 ++--
> 1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 49ca13abd108..5da8db3dda8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2787,16 +2787,16 @@ static void intel_encoder_get_config(struct
> intel_encoder *encoder,
> }
>
> static int intel_crtc_compute_config(struct intel_crtc *crtc,
> - struct intel_crtc_state *pipe_config)
> + struct intel_crtc_state *crtc_state)
> {
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct drm_display_mode *pipe_mode = &pipe_config->hw.pipe_mode;
> - int clock_limit = dev_priv->max_dotclk_freq;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
> + int clock_limit = i915->max_dotclk_freq;
>
> - drm_mode_copy(pipe_mode, &pipe_config->hw.adjusted_mode);
> + drm_mode_copy(pipe_mode, &crtc_state->hw.adjusted_mode);
>
> /* Adjust pipe_mode for bigjoiner, with half the horizontal mode */
> - if (pipe_config->bigjoiner) {
> + if (crtc_state->bigjoiner) {
> pipe_mode->crtc_clock /= 2;
> pipe_mode->crtc_hdisplay /= 2;
> pipe_mode->crtc_hblank_start /= 2;
> @@ -2804,12 +2804,12 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
> pipe_mode->crtc_hsync_start /= 2;
> pipe_mode->crtc_hsync_end /= 2;
> pipe_mode->crtc_htotal /= 2;
> - pipe_config->pipe_src_w /= 2;
> + crtc_state->pipe_src_w /= 2;
> }
>
> - if (pipe_config->splitter.enable) {
> - int n = pipe_config->splitter.link_count;
> - int overlap = pipe_config->splitter.pixel_overlap;
> + if (crtc_state->splitter.enable) {
> + int n = crtc_state->splitter.link_count;
> + int overlap = crtc_state->splitter.pixel_overlap;
>
> pipe_mode->crtc_hdisplay = (pipe_mode->crtc_hdisplay - overlap)
> * n;
> pipe_mode->crtc_hblank_start = (pipe_mode->crtc_hblank_start -
> overlap) * n;
> @@ -2822,8 +2822,8 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
>
> intel_mode_from_crtc_timings(pipe_mode, pipe_mode);
>
> - if (DISPLAY_VER(dev_priv) < 4) {
> - clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
> + if (DISPLAY_VER(i915) < 4) {
> + clock_limit = i915->max_cdclk_freq * 9 / 10;
>
> /*
>* Enable double wide mode when the dot clock
> @@ -2831,16 +2831,16 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
>*/
> if (intel_crtc_supports_double_wide(crtc) &&
> pipe_mode->crtc_clock > clock_limit) {
> - clock_limit = dev_priv->max_dotclk_freq;
> - pipe_config->double_wide = true;
> + clock_limit = i915->max_dotclk_freq;
> + crtc_state->double_wide = true;
> }
> }
>
> if (pipe_mode->crtc_clock > clock_limit) {
> - drm_dbg_kms(&dev_priv->drm,
> + drm_dbg_kms(&i915->drm,
> "requested pixel clock (%d kHz) too high (max: %d
> kHz, double wide: %s)\n",
> pipe_mode->crtc_clock, clock_limit,
> - yesno(pipe_config->double_wide));
> + yesno(crtc_state->double_wide));
> return -EINVAL;
> }
>
> @@ -2850,25 +2850,25 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
>* - LVDS dual channel mode
>* - Double wide pipe
>*/
> - if (pipe_config->pipe_src_w & 1) {
> - if (pipe_config->double_wide) {
> - drm_dbg_kms(&dev_priv->drm,
> + if (crtc_state->pipe_src_w & 1) {
> + if (crtc_state->double_wide) {
> + drm_dbg_kms(&i915->drm,
> "Odd pipe source width not supported with
> double wide pipe\n");
> return -EINVAL;
> }
>
> - if (intel_crtc_has_type(pipe_config, INTEL_OU
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Extract intel_bigjoiner_adjust_timings()
On Tue, Feb 15, 2022 at 08:32:01PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deduplicate the code to convert the full timings to
> per-pipe timings for bigjoiner usage.
>
> Signed-off-by: Ville Syrjälä
Makes sense to have a helper to do this:
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 41 +---
> 1 file changed, 18 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 70017526fa81..19417ff975c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2724,6 +2724,21 @@ static void intel_crtc_compute_pixel_rate(struct
> intel_crtc_state *crtc_state)
> ilk_pipe_pixel_rate(crtc_state);
> }
>
> +static void intel_bigjoiner_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> +struct drm_display_mode *mode)
> +{
> + if (!crtc_state->bigjoiner)
> + return;
> +
> + mode->crtc_clock /= 2;
> + mode->crtc_hdisplay /= 2;
> + mode->crtc_hblank_start /= 2;
> + mode->crtc_hblank_end /= 2;
> + mode->crtc_hsync_start /= 2;
> + mode->crtc_hsync_end /= 2;
> + mode->crtc_htotal /= 2;
> +}
> +
> static void intel_splitter_adjust_timings(const struct intel_crtc_state
> *crtc_state,
> struct drm_display_mode *mode)
> {
> @@ -2756,19 +2771,7 @@ static void intel_crtc_readout_derived_state(struct
> intel_crtc_state *crtc_state
>
> drm_mode_copy(pipe_mode, adjusted_mode);
>
> - if (crtc_state->bigjoiner) {
> - /*
> - * transcoder is programmed to the full mode,
> - * but pipe timings are half of the transcoder mode
> - */
> - pipe_mode->crtc_hdisplay /= 2;
> - pipe_mode->crtc_hblank_start /= 2;
> - pipe_mode->crtc_hblank_end /= 2;
> - pipe_mode->crtc_hsync_start /= 2;
> - pipe_mode->crtc_hsync_end /= 2;
> - pipe_mode->crtc_htotal /= 2;
> - pipe_mode->crtc_clock /= 2;
> - }
> + intel_bigjoiner_adjust_timings(crtc_state, pipe_mode);
>
> if (crtc_state->splitter.enable) {
> intel_splitter_adjust_timings(crtc_state, pipe_mode);
> @@ -2804,17 +2807,9 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
>
> drm_mode_copy(pipe_mode, &crtc_state->hw.adjusted_mode);
>
> - /* Adjust pipe_mode for bigjoiner, with half the horizontal mode */
> - if (crtc_state->bigjoiner) {
> - pipe_mode->crtc_clock /= 2;
> - pipe_mode->crtc_hdisplay /= 2;
> - pipe_mode->crtc_hblank_start /= 2;
> - pipe_mode->crtc_hblank_end /= 2;
> - pipe_mode->crtc_hsync_start /= 2;
> - pipe_mode->crtc_hsync_end /= 2;
> - pipe_mode->crtc_htotal /= 2;
> + intel_bigjoiner_adjust_timings(crtc_state, pipe_mode);
> + if (crtc_state->bigjoiner)
> crtc_state->pipe_src_w /= 2;
> - }
>
> intel_splitter_adjust_timings(crtc_state, pipe_mode);
>
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Extract intel_crtc_compute_pipe_src()
On Tue, Feb 15, 2022 at 08:32:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_crtc_compute_config() doesn't really tell a unified story.
> Let's chunk it up into pieces. We'll start with
> intel_crtc_compute_pipe_src().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
with just one clarification below
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 62
> 1 file changed, 39 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 19417ff975c6..3d3fddd3f452 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2798,18 +2798,55 @@ static void intel_encoder_get_config(struct
> intel_encoder *encoder,
> intel_crtc_readout_derived_state(crtc_state);
> }
>
> +static int intel_crtc_compute_pipe_src(struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> +
> + if (crtc_state->bigjoiner)
> + crtc_state->pipe_src_w /= 2;
> +
> + /*
> + * Pipe horizontal size must be even in:
> + * - DVO ganged mode
> + * - LVDS dual channel mode
> + * - Double wide pipe
> + */
> + if (crtc_state->pipe_src_w & 1) {
> + if (crtc_state->double_wide) {
> + drm_dbg_kms(&i915->drm,
> + "[CRTC:%d:%s] Odd pipe source width not
> supported with double wide pipe\n",
> + crtc->base.base.id, crtc->base.name);
> + return -EINVAL;
> + }
> +
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> + intel_is_dual_link_lvds(i915)) {
> + drm_dbg_kms(&i915->drm,
> + "[CRTC:%d:%s] Odd pipe source width not
> supported with dual link LVDS\n",
> + crtc->base.base.id, crtc->base.name);
> + return -EINVAL;
> + }
> + }
> +
> + return 0;
> +}
> +
> static int intel_crtc_compute_config(struct intel_crtc *crtc,
>struct intel_crtc_state *crtc_state)
> {
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
> int clock_limit = i915->max_dotclk_freq;
> + int ret;
> +
> + ret = intel_crtc_compute_pipe_src(crtc_state);
Here crtc_state->pipe_src_w would already have been populated right?
Just wanted to double check since we are moving this earlier in the function
Manasi
> + if (ret)
> + return ret;
>
> drm_mode_copy(pipe_mode, &crtc_state->hw.adjusted_mode);
>
> intel_bigjoiner_adjust_timings(crtc_state, pipe_mode);
> - if (crtc_state->bigjoiner)
> - crtc_state->pipe_src_w /= 2;
>
> intel_splitter_adjust_timings(crtc_state, pipe_mode);
>
> @@ -2837,27 +2874,6 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
> return -EINVAL;
> }
>
> - /*
> - * Pipe horizontal size must be even in:
> - * - DVO ganged mode
> - * - LVDS dual channel mode
> - * - Double wide pipe
> - */
> - if (crtc_state->pipe_src_w & 1) {
> - if (crtc_state->double_wide) {
> - drm_dbg_kms(&i915->drm,
> - "Odd pipe source width not supported with
> double wide pipe\n");
> - return -EINVAL;
> - }
> -
> - if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> - intel_is_dual_link_lvds(i915)) {
> - drm_dbg_kms(&i915->drm,
> - "Odd pipe source width not supported with
> dual link LVDS\n");
> - return -EINVAL;
> - }
> - }
> -
> intel_crtc_compute_pixel_rate(crtc_state);
>
> if (crtc_state->has_pch_encoder)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 07/12] drm/i915: Extract intel_crtc_compute_pipe_mode()
On Tue, Feb 15, 2022 at 08:32:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pull intel_crtc_compute_pipe_mode() out from
> intel_crtc_compute_config(). Since it's semi related
> we'll suck in the max dotclock/double wide checks in
> as well.
>
> And we'll pimp the debugs while at it.
>
> Signed-off-by: Ville Syrjälä
Yup looks lot more organized
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 28 ++--
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 3d3fddd3f452..6ff58164929c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2832,17 +2832,12 @@ static int intel_crtc_compute_pipe_src(struct
> intel_crtc_state *crtc_state)
> return 0;
> }
>
> -static int intel_crtc_compute_config(struct intel_crtc *crtc,
> - struct intel_crtc_state *crtc_state)
> +static int intel_crtc_compute_pipe_mode(struct intel_crtc_state *crtc_state)
> {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
> int clock_limit = i915->max_dotclk_freq;
> - int ret;
> -
> - ret = intel_crtc_compute_pipe_src(crtc_state);
> - if (ret)
> - return ret;
>
> drm_mode_copy(pipe_mode, &crtc_state->hw.adjusted_mode);
>
> @@ -2868,12 +2863,29 @@ static int intel_crtc_compute_config(struct
> intel_crtc *crtc,
>
> if (pipe_mode->crtc_clock > clock_limit) {
> drm_dbg_kms(&i915->drm,
> - "requested pixel clock (%d kHz) too high (max: %d
> kHz, double wide: %s)\n",
> + "[CRTC:%d:%s] requested pixel clock (%d kHz) too
> high (max: %d kHz, double wide: %s)\n",
> + crtc->base.base.id, crtc->base.name,
> pipe_mode->crtc_clock, clock_limit,
> yesno(crtc_state->double_wide));
> return -EINVAL;
> }
>
> + return 0;
> +}
> +
> +static int intel_crtc_compute_config(struct intel_crtc *crtc,
> + struct intel_crtc_state *crtc_state)
> +{
> + int ret;
> +
> + ret = intel_crtc_compute_pipe_src(crtc_state);
> + if (ret)
> + return ret;
> +
> + ret = intel_crtc_compute_pipe_mode(crtc_state);
> + if (ret)
> + return ret;
> +
> intel_crtc_compute_pixel_rate(crtc_state);
>
> if (crtc_state->has_pch_encoder)
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 06/12] drm/i915: Extract intel_crtc_compute_pipe_src()
On Wed, Feb 16, 2022 at 11:35:39AM -0800, Navare, Manasi wrote:
> On Tue, Feb 15, 2022 at 08:32:02PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > intel_crtc_compute_config() doesn't really tell a unified story.
> > Let's chunk it up into pieces. We'll start with
> > intel_crtc_compute_pipe_src().
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Manasi Navare
>
> with just one clarification below
>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 62
> > 1 file changed, 39 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 19417ff975c6..3d3fddd3f452 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -2798,18 +2798,55 @@ static void intel_encoder_get_config(struct
> > intel_encoder *encoder,
> > intel_crtc_readout_derived_state(crtc_state);
> > }
> >
> > +static int intel_crtc_compute_pipe_src(struct intel_crtc_state *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > +
> > + if (crtc_state->bigjoiner)
> > + crtc_state->pipe_src_w /= 2;
> > +
> > + /*
> > +* Pipe horizontal size must be even in:
> > +* - DVO ganged mode
> > +* - LVDS dual channel mode
> > +* - Double wide pipe
> > +*/
> > + if (crtc_state->pipe_src_w & 1) {
> > + if (crtc_state->double_wide) {
> > + drm_dbg_kms(&i915->drm,
> > + "[CRTC:%d:%s] Odd pipe source width not
> > supported with double wide pipe\n",
> > + crtc->base.base.id, crtc->base.name);
> > + return -EINVAL;
> > + }
> > +
> > + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> > + intel_is_dual_link_lvds(i915)) {
> > + drm_dbg_kms(&i915->drm,
> > + "[CRTC:%d:%s] Odd pipe source width not
> > supported with dual link LVDS\n",
> > + crtc->base.base.id, crtc->base.name);
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int intel_crtc_compute_config(struct intel_crtc *crtc,
> > struct intel_crtc_state *crtc_state)
> > {
> > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > struct drm_display_mode *pipe_mode = &crtc_state->hw.pipe_mode;
> > int clock_limit = i915->max_dotclk_freq;
> > + int ret;
> > +
> > + ret = intel_crtc_compute_pipe_src(crtc_state);
>
> Here crtc_state->pipe_src_w would already have been populated right?
> Just wanted to double check since we are moving this earlier in the function
Yeah it's initially set up already in intel_modeset_pipe_config()
before even calling the encoder compute_config() hooks, and
intel_crtc_compute_config() gets called after those.
I'd actually prefer to calculate it completely here, but we
currently set up the panel fitter stuff already in the
encoder->compute_config() hook. So the order has to as is,
for the moment at least.
--
Ville Syrjälä
Intel
