From: Matt Roper <matthew.d.roper@intel.com>
To: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 09/11] drm/i915/mtl: Update MBUS_DBOX credits
Date: Thu, 8 Sep 2022 13:02:35 -0700 [thread overview]
Message-ID: <YxpKWw+EqKgj3i1f@mdroper-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <20220902060342.151824-10-radhakrishna.sripada@intel.com>
On Thu, Sep 01, 2022 at 11:03:40PM -0700, Radhakrishna Sripada wrote:
> Display version 14 platforms have different credits values
> compared to ADL-P. Update the credits based on pipe usage.
>
> v2: Simplify DBOX BW Credit definition(MattR)
>
> Bspec: 49213
>
> Cc: Jose Roberto de Souza <jose.souza@intel.com>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Original Author: Caz Yokoyama
> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 +++
> drivers/gpu/drm/i915/intel_pm.c | 47 ++++++++++++++++++++++++++++++---
> 2 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d22fabe35a0c..f9237586ab4f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1125,8 +1125,12 @@
> #define MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN REG_BIT(16) /* tgl+ */
> #define MBUS_DBOX_BW_CREDIT_MASK REG_GENMASK(15, 14)
> #define MBUS_DBOX_BW_CREDIT(x) REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, x)
> +#define MBUS_DBOX_BW_4CREDITS_MTL REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, 0x2)
> +#define MBUS_DBOX_BW_8CREDITS_MTL REG_FIELD_PREP(MBUS_DBOX_BW_CREDIT_MASK, 0x3)
> #define MBUS_DBOX_B_CREDIT_MASK REG_GENMASK(12, 8)
> #define MBUS_DBOX_B_CREDIT(x) REG_FIELD_PREP(MBUS_DBOX_B_CREDIT_MASK, x)
> +#define MBUS_DBOX_I_CREDIT_MASK REG_GENMASK(7, 5)
> +#define MBUS_DBOX_I_CREDIT(x) REG_FIELD_PREP(MBUS_DBOX_I_CREDIT_MASK, x)
> #define MBUS_DBOX_A_CREDIT_MASK REG_GENMASK(3, 0)
> #define MBUS_DBOX_A_CREDIT(x) REG_FIELD_PREP(MBUS_DBOX_A_CREDIT_MASK, x)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ebce6171ccef..b19a1ecb010e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8448,6 +8448,27 @@ void intel_dbuf_post_plane_update(struct intel_atomic_state *state)
> new_dbuf_state->enabled_slices);
> }
>
> +static bool xelpdp_is_one_pipe_per_dbuf_bank(enum pipe pipe, u8 active_pipes)
Bikeshed: s/one/only/ might be slightly more clear?
> +{
> + switch (pipe) {
> + case PIPE_A:
> + case PIPE_D:
> + if (is_power_of_2(active_pipes & (BIT(PIPE_A) | BIT(PIPE_D))))
Bikeshed: writing this with hweight might be more intuitive than
power_of_2? Or even just a direct check of the other pipe like
case PIPE_A:
return !(active_pipes & BIT(PIPE_D))
case PIPE_D:
return !(active_pipes & BIT(PIPE_A))
...
> + return true;
> + break;
> + case PIPE_B:
> + case PIPE_C:
> + if (is_power_of_2(active_pipes & (BIT(PIPE_B) | BIT(PIPE_C))))
> + return true;
> + break;
> + default: /* to suppress compiler warning */
> + MISSING_CASE(pipe);
> + break;
> + }
> +
> + return false;
> +}
> +
> void intel_mbus_dbox_update(struct intel_atomic_state *state)
> {
> struct drm_i915_private *i915 = to_i915(state->base.dev);
> @@ -8467,20 +8488,28 @@ void intel_mbus_dbox_update(struct intel_atomic_state *state)
> new_dbuf_state->active_pipes == old_dbuf_state->active_pipes))
> return;
>
> + if (DISPLAY_VER(i915) >= 14)
> + val |= MBUS_DBOX_I_CREDIT(2);
> +
> if (DISPLAY_VER(i915) >= 12) {
> val |= MBUS_DBOX_B2B_TRANSACTIONS_MAX(16);
> val |= MBUS_DBOX_B2B_TRANSACTIONS_DELAY(1);
> val |= MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN;
> }
>
> - /* Wa_22010947358:adl-p */
> - if (IS_ALDERLAKE_P(i915))
> + if (DISPLAY_VER(i915) >= 14)
> + val |= new_dbuf_state->joined_mbus ? MBUS_DBOX_A_CREDIT(12) :
> + MBUS_DBOX_A_CREDIT(8);
> + else if (IS_ALDERLAKE_P(i915))
> + /* Wa_22010947358:adl-p */
> val |= new_dbuf_state->joined_mbus ? MBUS_DBOX_A_CREDIT(6) :
> MBUS_DBOX_A_CREDIT(4);
> else
> val |= MBUS_DBOX_A_CREDIT(2);
>
> - if (IS_ALDERLAKE_P(i915)) {
> + if (DISPLAY_VER(i915) >= 14) {
> + val |= MBUS_DBOX_B_CREDIT(0xA);
> + } else if (IS_ALDERLAKE_P(i915)) {
> val |= MBUS_DBOX_BW_CREDIT(2);
> val |= MBUS_DBOX_B_CREDIT(8);
> } else if (DISPLAY_VER(i915) >= 12) {
> @@ -8492,10 +8521,20 @@ void intel_mbus_dbox_update(struct intel_atomic_state *state)
> }
>
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + u32 pipe_val = val;
> +
> if (!new_crtc_state->hw.active ||
> !intel_crtc_needs_modeset(new_crtc_state))
> continue;
What if the number of BW credits for a pipe changes when this pipe
itself isn't undergoing a modeset? E.g., what if you initially had pipe
A active as the only pipe and thus programmed 8 BW credits. Then you
turn on pipe D; since we're not touching pipe A directly we skip any
programming here (leaving it at 8 credits) and only program the 4
credits for pipe D's instance of the register. Am I missing something
here?
Matt
>
> - intel_de_write(i915, PIPE_MBUS_DBOX_CTL(crtc->pipe), val);
> + if (DISPLAY_VER(i915) >= 14) {
> + if (xelpdp_is_one_pipe_per_dbuf_bank(crtc->pipe,
> + new_dbuf_state->active_pipes))
> + pipe_val |= MBUS_DBOX_BW_8CREDITS_MTL;
> + else
> + pipe_val |= MBUS_DBOX_BW_4CREDITS_MTL;
> + }
> +
> + intel_de_write(i915, PIPE_MBUS_DBOX_CTL(crtc->pipe), pipe_val);
> }
> }
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
next prev parent reply other threads:[~2022-09-08 20:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-02 6:03 [PATCH v4 00/11] Initial Meteorlake Support Radhakrishna Sripada
2022-09-02 6:03 ` [PATCH v4 01/11] drm/i915: Move display and media IP version to runtime info Radhakrishna Sripada
2022-09-02 16:49 ` kernel test robot
2022-09-02 22:10 ` [PATCH v4.1] " Radhakrishna Sripada
2022-09-08 17:21 ` Matt Roper
2022-09-02 6:03 ` [PATCH v4 02/11] drm/i915: Read graphics/media/display arch version from hw Radhakrishna Sripada
2022-09-07 20:49 ` [Intel-gfx] " Lucas De Marchi
2022-09-07 22:13 ` Matt Roper
2022-09-07 22:21 ` Lucas De Marchi
2022-09-07 22:38 ` Sripada, Radhakrishna
2022-09-07 23:32 ` [PATCH v4.1] " Radhakrishna Sripada
2022-09-02 6:03 ` [PATCH v4 03/11] drm/i915: Parse and set stepping for platforms with GMD Radhakrishna Sripada
2022-09-08 17:42 ` [Intel-gfx] " Matt Roper
2022-09-02 6:03 ` [PATCH v4 04/11] drm/i915/mtl: Define engine context layouts Radhakrishna Sripada
2022-09-06 12:16 ` Balasubramani Vivekanandan
2022-09-07 23:33 ` [PATCH v4.1] " Radhakrishna Sripada
2022-09-08 18:00 ` [Intel-gfx] " Matt Roper
2022-09-02 6:03 ` [PATCH v4 05/11] drm/i915/mtl: Add gmbus and gpio support Radhakrishna Sripada
2022-09-08 13:05 ` [Intel-gfx] " Balasubramani Vivekanandan
2022-09-08 18:02 ` Matt Roper
2022-09-02 6:03 ` [PATCH v4 06/11] drm/i915/mtl: Add display power wells Radhakrishna Sripada
2022-09-08 18:07 ` Matt Roper
2022-09-08 18:11 ` Matt Roper
2022-09-02 6:03 ` [PATCH v4 07/11] drm/i915/mtl: Add DP AUX support on TypeC ports Radhakrishna Sripada
2022-09-08 18:13 ` Matt Roper
2022-09-02 6:03 ` [PATCH v4 08/11] drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox Radhakrishna Sripada
2022-09-02 6:03 ` [PATCH v4 09/11] drm/i915/mtl: Update MBUS_DBOX credits Radhakrishna Sripada
2022-09-08 20:02 ` Matt Roper [this message]
2022-09-02 6:03 ` [PATCH v4 10/11] drm/i915/mtl: Update CHICKEN_TRANS* register addresses Radhakrishna Sripada
2022-09-08 20:30 ` Matt Roper
2022-09-02 6:03 ` [PATCH v4 11/11] drm/i915/mtl: Do not update GV point, mask value Radhakrishna Sripada
2022-09-09 17:14 ` [Intel-gfx] " Balasubramani Vivekanandan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YxpKWw+EqKgj3i1f@mdroper-desk1.amr.corp.intel.com \
--to=matthew.d.roper@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=radhakrishna.sripada@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).