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:10:38 +0300 [thread overview]
Message-ID: <877d3guzf5.fsf@intel.com> (raw)
In-Reply-To: <87a68cuzh5.fsf@intel.com>
On Wed, 10 Aug 2022, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> 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.
And to elaborate, this kind of stuff should happen upstream months
before anyone's even heard of the new platform!
BR,
Jani.
>
>>
>>
>> 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
next prev parent reply other threads:[~2022-08-10 11:10 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
2022-08-10 11:10 ` Jani Nikula [this message]
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=877d3guzf5.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