dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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

  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).