From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Sk Anirban <sk.anirban@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <anshuman.gupta@intel.com>,
<badal.nilawar@intel.com>, <riana.tauro@intel.com>,
<karthik.poosa@intel.com>, <raag.jadav@intel.com>,
<soham.purkait@intel.com>, <mallesh.koujalagi@intel.com>,
<vinay.belgaumkar@intel.com>
Subject: Re: [PATCH v6 1/2] drm/xe/guc: Eliminate RPe caching for SLPC parameter handling
Date: Fri, 7 Nov 2025 22:23:16 -0500 [thread overview]
Message-ID: <aQ63pHic8tUHW13w@intel.com> (raw)
In-Reply-To: <20251104195735.1606126-5-sk.anirban@intel.com>
On Wed, Nov 05, 2025 at 01:27:37AM +0530, Sk Anirban wrote:
> RPe is runtime-determined by PCODE and caching it caused stale values,
> leading to incorrect GuC SLPC parameter settings.
> Drop the cached rpe_freq field and query fresh values from hardware
> on each use to ensure GuC SLPC parameters reflect current RPe.
>
> v2: Remove cached RPe frequency field (Rodrigo)
> v3: Remove extra variable (Vinay)
> Modify function name (Vinay)
> v4: Maintain a separate function for PVC (Rodrigo)
> v5: Avoid RPn update while fetching RPe frequency (Rodrigo)
dang, now I regret on having asked that... I'm not trusting on the
CI results any longer.
Did you run this full xe_gt_freq tests in your machine?
I forgot the machine that made us to introduce this rpn hack...
>
> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5166
> Signed-off-by: Sk Anirban <sk.anirban@intel.com>
> ---
> drivers/gpu/drm/xe/xe_guc_pc.c | 68 ++++++++++++++--------------
> drivers/gpu/drm/xe/xe_guc_pc_types.h | 2 -
> 2 files changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_guc_pc.c b/drivers/gpu/drm/xe/xe_guc_pc.c
> index ff22235857f8..efa9318c4587 100644
> --- a/drivers/gpu/drm/xe/xe_guc_pc.c
> +++ b/drivers/gpu/drm/xe/xe_guc_pc.c
> @@ -331,7 +331,7 @@ static int pc_set_min_freq(struct xe_guc_pc *pc, u32 freq)
> * Our goal is to have the admin choices respected.
> */
> pc_action_set_param(pc, SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
> - freq < pc->rpe_freq);
> + freq < xe_guc_pc_get_rpe_freq(pc));
>
> return pc_action_set_param(pc,
> SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
> @@ -376,7 +376,7 @@ static void mtl_update_rpa_value(struct xe_guc_pc *pc)
> pc->rpa_freq = decode_freq(REG_FIELD_GET(MTL_RPA_MASK, reg));
> }
>
> -static void mtl_update_rpe_value(struct xe_guc_pc *pc)
> +static u32 mtl_get_rpe_freq(struct xe_guc_pc *pc)
> {
> struct xe_gt *gt = pc_to_gt(pc);
> u32 reg;
> @@ -386,7 +386,7 @@ static void mtl_update_rpe_value(struct xe_guc_pc *pc)
> else
> reg = xe_mmio_read32(>->mmio, MTL_GT_RPE_FREQUENCY);
>
> - pc->rpe_freq = decode_freq(REG_FIELD_GET(MTL_RPE_MASK, reg));
> + return decode_freq(REG_FIELD_GET(MTL_RPE_MASK, reg));
> }
>
> static void tgl_update_rpa_value(struct xe_guc_pc *pc)
> @@ -409,24 +409,22 @@ static void tgl_update_rpa_value(struct xe_guc_pc *pc)
> }
> }
>
> -static void tgl_update_rpe_value(struct xe_guc_pc *pc)
> +static u32 pvc_get_rpe_freq(struct xe_guc_pc *pc)
> {
> struct xe_gt *gt = pc_to_gt(pc);
> - struct xe_device *xe = gt_to_xe(gt);
> u32 reg;
>
> - /*
> - * For PVC we still need to use fused RP1 as the approximation for RPe
> - * For other platforms than PVC we get the resolved RPe directly from
> - * PCODE at a different register
> - */
> - if (xe->info.platform == XE_PVC) {
> - reg = xe_mmio_read32(>->mmio, PVC_RP_STATE_CAP);
> - pc->rpe_freq = REG_FIELD_GET(RP1_MASK, reg) * GT_FREQUENCY_MULTIPLIER;
> - } else {
> - reg = xe_mmio_read32(>->mmio, FREQ_INFO_REC);
> - pc->rpe_freq = REG_FIELD_GET(RPE_MASK, reg) * GT_FREQUENCY_MULTIPLIER;
> - }
> + reg = xe_mmio_read32(>->mmio, PVC_RP_STATE_CAP);
> + return REG_FIELD_GET(RP1_MASK, reg) * GT_FREQUENCY_MULTIPLIER;
> +}
> +
> +static u32 tgl_get_rpe_freq(struct xe_guc_pc *pc)
> +{
> + struct xe_gt *gt = pc_to_gt(pc);
> + u32 reg;
> +
> + reg = xe_mmio_read32(>->mmio, FREQ_INFO_REC);
> + return REG_FIELD_GET(RPE_MASK, reg) * GT_FREQUENCY_MULTIPLIER;
> }
>
> static void pc_update_rp_values(struct xe_guc_pc *pc)
> @@ -434,20 +432,10 @@ static void pc_update_rp_values(struct xe_guc_pc *pc)
> struct xe_gt *gt = pc_to_gt(pc);
> struct xe_device *xe = gt_to_xe(gt);
>
> - if (GRAPHICS_VERx100(xe) >= 1270) {
> + if (GRAPHICS_VERx100(xe) >= 1270)
> mtl_update_rpa_value(pc);
> - mtl_update_rpe_value(pc);
> - } else {
> + else
> tgl_update_rpa_value(pc);
> - tgl_update_rpe_value(pc);
> - }
> -
> - /*
> - * RPe is decided at runtime by PCODE. In the rare case where that's
> - * smaller than the fused min, we will trust the PCODE and use that
> - * as our minimum one.
> - */
> - pc->rpn_freq = min(pc->rpn_freq, pc->rpe_freq);
> }
>
> /**
> @@ -561,9 +549,23 @@ u32 xe_guc_pc_get_rpa_freq(struct xe_guc_pc *pc)
> */
> u32 xe_guc_pc_get_rpe_freq(struct xe_guc_pc *pc)
> {
> - pc_update_rp_values(pc);
> + struct xe_gt *gt = pc_to_gt(pc);
> + struct xe_device *xe = gt_to_xe(gt);
> + u32 freq;
>
> - return pc->rpe_freq;
> + /*
> + * For PVC we still need to use fused RP1 as the approximation for RPe
> + * For other platforms than PVC we get the resolved RPe directly from
> + * PCODE at a different register
> + */
> + if (GRAPHICS_VERx100(xe) == 1260)
> + freq = pvc_get_rpe_freq(pc);
> + else if (GRAPHICS_VERx100(xe) >= 1270)
> + freq = mtl_get_rpe_freq(pc);
> + else
> + freq = tgl_get_rpe_freq(pc);
> +
> + return freq;
> }
>
> /**
> @@ -1022,7 +1024,7 @@ static int pc_set_mert_freq_cap(struct xe_guc_pc *pc)
> /*
> * Ensure min and max are bound by MERT_FREQ_CAP until driver loads.
> */
> - ret = pc_set_min_freq(pc, min(pc->rpe_freq, pc_max_freq_cap(pc)));
> + ret = pc_set_min_freq(pc, min(xe_guc_pc_get_rpe_freq(pc), pc_max_freq_cap(pc)));
> if (!ret)
> ret = pc_set_max_freq(pc, min(pc->rp0_freq, pc_max_freq_cap(pc)));
>
> @@ -1340,7 +1342,7 @@ static void xe_guc_pc_fini_hw(void *arg)
> XE_WARN_ON(xe_guc_pc_stop(pc));
>
> /* Bind requested freq to mert_freq_cap before unload */
> - pc_set_cur_freq(pc, min(pc_max_freq_cap(pc), pc->rpe_freq));
> + pc_set_cur_freq(pc, min(pc_max_freq_cap(pc), xe_guc_pc_get_rpe_freq(pc)));
>
> xe_force_wake_put(gt_to_fw(pc_to_gt(pc)), fw_ref);
> }
> diff --git a/drivers/gpu/drm/xe/xe_guc_pc_types.h b/drivers/gpu/drm/xe/xe_guc_pc_types.h
> index 5e4ea53fbee6..f27c05d81706 100644
> --- a/drivers/gpu/drm/xe/xe_guc_pc_types.h
> +++ b/drivers/gpu/drm/xe/xe_guc_pc_types.h
> @@ -21,8 +21,6 @@ struct xe_guc_pc {
> u32 rp0_freq;
> /** @rpa_freq: HW RPa frequency - The Achievable one */
> u32 rpa_freq;
> - /** @rpe_freq: HW RPe frequency - The Efficient one */
> - u32 rpe_freq;
> /** @rpn_freq: HW RPN frequency - The Minimum one */
> u32 rpn_freq;
> /** @user_requested_min: Stash the minimum requested freq by user */
> --
> 2.43.0
>
next prev parent reply other threads:[~2025-11-08 3:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 19:57 [PATCH v6 0/2] drm/xe/guc: Remove cached frequency values for GuC SLPC Sk Anirban
2025-11-04 19:57 ` [PATCH v6 1/2] drm/xe/guc: Eliminate RPe caching for SLPC parameter handling Sk Anirban
2025-11-07 1:51 ` Belgaumkar, Vinay
2025-11-08 3:23 ` Rodrigo Vivi [this message]
2025-11-10 9:46 ` Anirban, Sk
2025-11-04 19:57 ` [PATCH v6 2/2] drm/xe/guc: Eliminate RPa frequency caching Sk Anirban
2025-11-08 3:21 ` Rodrigo Vivi
2025-11-05 2:51 ` ✓ CI.KUnit: success for drm/xe/guc: Remove cached frequency values for GuC SLPC (rev3) Patchwork
2025-11-05 3:54 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-05 9:46 ` ✓ Xe.CI.Full: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2025-11-12 18:51 [PATCH v6 0/2] drm/xe/guc: Remove cached frequency values for GuC SLPC Sk Anirban
2025-11-12 18:51 ` [PATCH v6 1/2] drm/xe/guc: Eliminate RPe caching for SLPC parameter handling Sk Anirban
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=aQ63pHic8tUHW13w@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=karthik.poosa@intel.com \
--cc=mallesh.koujalagi@intel.com \
--cc=raag.jadav@intel.com \
--cc=riana.tauro@intel.com \
--cc=sk.anirban@intel.com \
--cc=soham.purkait@intel.com \
--cc=vinay.belgaumkar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.