public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Matt Roper <matthew.d.roper@intel.com>,
	Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 13/23] drm/i915/mtl: memory latency data from LATENCY_LPX_LPY for WM
Date: Wed, 10 Aug 2022 14:09:26 +0300	[thread overview]
Message-ID: <87a68cuzh5.fsf@intel.com> (raw)
In-Reply-To: <YulM8L/G8ZJFQMYe@mdroper-desk1.amr.corp.intel.com>

On Tue, 02 Aug 2022, Matt Roper <matthew.d.roper@intel.com> wrote:
> On Wed, Jul 27, 2022 at 06:34:10PM -0700, Radhakrishna Sripada wrote:
>> Since Xe LPD+, Memory latency data are in LATENCY_LPX_LPY registers
>> instead of GT driver mailbox.
>> 
>> Bspec: 64608
>> 
>> Cc: Matt Roper <matthew.d.roper@intel.com>
>> Original Author: Caz Yokoyama
>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h |   7 +++
>>  drivers/gpu/drm/i915/intel_pm.c | 105 +++++++++++++++++++-------------
>>  2 files changed, 71 insertions(+), 41 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>> index 6087d40eed70..23b50d671550 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -8754,4 +8754,11 @@ enum skl_power_gate {
>>  #define GEN12_STATE_ACK_DEBUG		_MMIO(0x20BC)
>>  
>>  #define MTL_MEDIA_GSI_BASE		0x380000
>> +
>> +#define MTL_LATENCY_LP0_LP1		_MMIO(0x45780)
>> +#define MTL_LATENCY_LP2_LP3		_MMIO(0x45784)
>> +#define MTL_LATENCY_LP4_LP5		_MMIO(0x45788)
>> +#define  MTL_LATENCY_LEVEL0_2_4_MASK	REG_GENMASK(12, 0)
>> +#define  MTL_LATENCY_LEVEL1_3_5_MASK	REG_GENMASK(28, 16)
>> +
>>  #endif /* _I915_REG_H_ */
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>> index ef7553b494ea..fac565d23d57 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -2861,16 +2861,75 @@ static void ilk_compute_wm_level(const struct drm_i915_private *dev_priv,
>>  	result->enable = true;
>>  }
>>  
>> +static void
>> +adjust_wm_latency(u16 wm[], int max_level, int read_latency,
>> +		  bool wm_lv_0_adjust_needed)
>
> The refactoring to separate the adjustment from the readout should
> probably be a separate patch before you add the MTL-specific changes on
> top.

Agreed.

>
>
> Matt
>
>> +{
>> +	int i, level;
>> +
>> +	/*
>> +	 * If a level n (n > 1) has a 0us latency, all levels m (m >= n)
>> +	 * need to be disabled. We make sure to sanitize the values out
>> +	 * of the punit to satisfy this requirement.
>> +	 */
>> +	for (level = 1; level <= max_level; level++) {
>> +		if (wm[level] == 0) {
>> +			for (i = level + 1; i <= max_level; i++)
>> +				wm[i] = 0;
>> +
>> +			max_level = level - 1;
>> +			break;
>> +		}
>> +	}
>> +
>> +	/*
>> +	 * WaWmMemoryReadLatency
>> +	 *
>> +	 * punit doesn't take into account the read latency so we need
>> +	 * to add proper adjustement to each valid level we retrieve
>> +	 * from the punit when level 0 response data is 0us.
>> +	 */
>> +	if (wm[0] == 0) {
>> +		for (level = 0; level <= max_level; level++)
>> +			wm[level] += read_latency;
>> +	}
>> +
>> +	/*
>> +	 * WA Level-0 adjustment for 16GB DIMMs: SKL+
>> +	 * If we could not get dimm info enable this WA to prevent from
>> +	 * any underrun. If not able to get Dimm info assume 16GB dimm
>> +	 * to avoid any underrun.
>> +	 */
>> +	if (wm_lv_0_adjust_needed)
>> +		wm[0] += 1;
>> +}
>> +
>>  static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
>>  				  u16 wm[])
>>  {
>>  	struct intel_uncore *uncore = &dev_priv->uncore;
>> +	int max_level = ilk_wm_max_level(dev_priv);
>>  
>> -	if (DISPLAY_VER(dev_priv) >= 9) {
>> +	if (DISPLAY_VER(dev_priv) >= 14) {
>>  		u32 val;
>> -		int ret, i;
>> -		int level, max_level = ilk_wm_max_level(dev_priv);
>> +
>> +		val = intel_uncore_read(uncore, MTL_LATENCY_LP0_LP1);
>> +		wm[0] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
>> +		wm[1] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
>> +		val = intel_uncore_read(uncore, MTL_LATENCY_LP2_LP3);
>> +		wm[2] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
>> +		wm[3] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
>> +		val = intel_uncore_read(uncore, MTL_LATENCY_LP4_LP5);
>> +		wm[4] = REG_FIELD_GET(MTL_LATENCY_LEVEL0_2_4_MASK, val);
>> +		wm[5] = REG_FIELD_GET(MTL_LATENCY_LEVEL1_3_5_MASK, val);
>> +
>> +		adjust_wm_latency(wm, max_level, 6,
>> +				  dev_priv->dram_info.wm_lv_0_adjust_needed);
>> +	} else if (DISPLAY_VER(dev_priv) >= 9) {
>> +		int read_latency = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
>>  		int mult = IS_DG2(dev_priv) ? 2 : 1;
>> +		u32 val;
>> +		int ret;
>>  
>>  		/* read the first set of memory latencies[0:3] */
>>  		val = 0; /* data0 to be programmed to 0 for first set */
>> @@ -2909,44 +2968,8 @@ static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
>>  		wm[7] = ((val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
>>  				GEN9_MEM_LATENCY_LEVEL_MASK) * mult;
>>  
>> -		/*
>> -		 * If a level n (n > 1) has a 0us latency, all levels m (m >= n)
>> -		 * need to be disabled. We make sure to sanitize the values out
>> -		 * of the punit to satisfy this requirement.
>> -		 */
>> -		for (level = 1; level <= max_level; level++) {
>> -			if (wm[level] == 0) {
>> -				for (i = level + 1; i <= max_level; i++)
>> -					wm[i] = 0;
>> -
>> -				max_level = level - 1;
>> -
>> -				break;
>> -			}
>> -		}
>> -
>> -		/*
>> -		 * WaWmMemoryReadLatency
>> -		 *
>> -		 * punit doesn't take into account the read latency so we need
>> -		 * to add proper adjustement to each valid level we retrieve
>> -		 * from the punit when level 0 response data is 0us.
>> -		 */
>> -		if (wm[0] == 0) {
>> -			u8 adjust = DISPLAY_VER(dev_priv) >= 12 ? 3 : 2;
>> -
>> -			for (level = 0; level <= max_level; level++)
>> -				wm[level] += adjust;
>> -		}
>> -
>> -		/*
>> -		 * WA Level-0 adjustment for 16GB DIMMs: SKL+
>> -		 * If we could not get dimm info enable this WA to prevent from
>> -		 * any underrun. If not able to get Dimm info assume 16GB dimm
>> -		 * to avoid any underrun.
>> -		 */
>> -		if (dev_priv->dram_info.wm_lv_0_adjust_needed)
>> -			wm[0] += 1;
>> +		adjust_wm_latency(wm, max_level, read_latency,
>> +				  dev_priv->dram_info.wm_lv_0_adjust_needed);
>>  	} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>>  		u64 sskpd = intel_uncore_read64(uncore, MCH_SSKPD);
>>  
>> -- 
>> 2.25.1
>> 

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-08-10 11:09 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-28  1:33 [Intel-gfx] [PATCH 00/23] Initial Meteorlake Support Radhakrishna Sripada
2022-07-28  1:33 ` [Intel-gfx] [PATCH 01/23] drm/i915: Read graphics/media/display arch version from hw Radhakrishna Sripada
2022-07-28  3:46   ` [Intel-gfx] [v1.1 " Radhakrishna Sripada
2022-08-10 11:02     ` Jani Nikula
2022-08-10 13:23       ` Jani Nikula
2022-08-18 14:58     ` Balasubramani Vivekanandan
2022-07-28  1:33 ` [Intel-gfx] [PATCH 02/23] drm/i915: Parse and set stepping for platforms with GMD Radhakrishna Sripada
2022-07-28  1:34 ` [Intel-gfx] [PATCH 03/23] drm/i915/mtl: MMIO range is now 4MB Radhakrishna Sripada
2022-07-28  1:34 ` [Intel-gfx] [PATCH 04/23] drm/i915/mtl: Don't mask off CCS according to DSS fusing Radhakrishna Sripada
2022-07-28  1:34 ` [Intel-gfx] [PATCH 05/23] drm/i915/mtl: Define engine context layouts Radhakrishna Sripada
2022-07-28  1:34 ` [Intel-gfx] [PATCH 06/23] drm/i915/mtl: Add PCH support Radhakrishna Sripada
2022-07-28 21:28   ` Srivatsa, Anusha
2022-07-28  1:34 ` [Intel-gfx] [PATCH 07/23] drm/i915/mtl: Add gmbus and gpio support Radhakrishna Sripada
2022-08-01 21:33   ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 08/23] drm/i915/mtl: Add VBT port and AUX_CH mapping Radhakrishna Sripada
2022-08-01 21:45   ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 09/23] drm/i915/mtl: Add support for MTL in Display Init sequences Radhakrishna Sripada
2022-08-01 21:49   ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 10/23] drm/i915/mtl: Add display power wells Radhakrishna Sripada
2022-08-02  1:23   ` Matt Roper
2022-08-02 15:40     ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 11/23] drm/i915/mtl: Add DP AUX support on TypeC ports Radhakrishna Sripada
2022-08-02 15:41   ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 12/23] drm/i915/mtl: Fix rawclk for Meteorlake PCH Radhakrishna Sripada
2022-08-02  3:28   ` Matt Roper
2022-08-02  3:36     ` Caz Yokoyama
2022-07-28  1:34 ` [Intel-gfx] [PATCH 13/23] drm/i915/mtl: memory latency data from LATENCY_LPX_LPY for WM Radhakrishna Sripada
2022-08-02 16:12   ` Matt Roper
2022-08-10 11:09     ` Jani Nikula [this message]
2022-08-10 11:10       ` Jani Nikula
2022-07-28  1:34 ` [Intel-gfx] [PATCH 14/23] drm/i915/mtl: Add CDCLK Support Radhakrishna Sripada
2022-07-28  1:34 ` [Intel-gfx] [PATCH 15/23] drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox Radhakrishna Sripada
2022-08-02 16:43   ` Matt Roper
2022-08-02 16:53   ` Caz Yokoyama
2022-08-10 11:14   ` Jani Nikula
2022-07-28  1:34 ` [Intel-gfx] [PATCH 16/23] drm/i915/mtl: Update memory bandwidth parameters Radhakrishna Sripada
2022-08-02 16:52   ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 17/23] drm/i915/mtl: Update MBUS_DBOX credits Radhakrishna Sripada
2022-08-02 17:14   ` Matt Roper
2022-08-03 13:55   ` Balasubramani Vivekanandan
2022-07-28  1:34 ` [Intel-gfx] [PATCH 18/23] drm/i915/mtl: DBUF handling is same as adlp Radhakrishna Sripada
2022-08-02 17:35   ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 19/23] drm/i915/display/mtl: Extend MBUS programming Radhakrishna Sripada
2022-08-02 17:39   ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 20/23] drm/i915/dmc: Load DMC on MTL Radhakrishna Sripada
2022-08-02 18:00   ` Matt Roper
2022-07-28  1:34 ` [Intel-gfx] [PATCH 21/23] drm/i915/dmc: MTL DMC debugfs entries Radhakrishna Sripada
2022-08-02 18:22   ` Matt Roper
2022-08-09 18:06     ` Srivatsa, Anusha
2022-07-28  1:34 ` [Intel-gfx] [PATCH 22/23] drm/i915/mtl: Update CHICKEN_TRANS* register addresses Radhakrishna Sripada
2022-08-10 11:21   ` Jani Nikula
2022-07-28  1:34 ` [Intel-gfx] [PATCH 23/23] drm/i915/mtl: Do not update GV point, mask value Radhakrishna Sripada
2022-07-28  1:54 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Initial Meteorlake Support Patchwork
2022-08-02  3:26 ` [Intel-gfx] [PATCH 00/23] " Matt Roper
2022-08-04  9:08 ` Jani Nikula
2022-08-04 13:10   ` Jani Nikula

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=87a68cuzh5.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@intel.com \
    --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