From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/slpc: Use platform limits for min/max frequency
Date: Thu, 20 Oct 2022 15:57:09 -0700 [thread overview]
Message-ID: <8735biqf22.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20221018183031.33704-1-vinay.belgaumkar@intel.com>
On Tue, 18 Oct 2022 11:30:31 -0700, Vinay Belgaumkar wrote:
>
Hi Vinay,
> diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c b/drivers/gpu/drm/i915/gt/selftest_slpc.c
> index 4c6e9257e593..e42bc215e54d 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
> @@ -234,6 +234,7 @@ static int run_test(struct intel_gt *gt, int test_type)
> enum intel_engine_id id;
> struct igt_spinner spin;
> u32 slpc_min_freq, slpc_max_freq;
> + u32 saved_min_freq;
> int err = 0;
>
> if (!intel_uc_uses_guc_slpc(>->uc))
> @@ -252,20 +253,35 @@ static int run_test(struct intel_gt *gt, int test_type)
> return -EIO;
> }
>
> - /*
> - * FIXME: With efficient frequency enabled, GuC can request
> - * frequencies higher than the SLPC max. While this is fixed
> - * in GuC, we level set these tests with RPn as min.
> - */
> - err = slpc_set_min_freq(slpc, slpc->min_freq);
> - if (err)
> - return err;
> + if (slpc_min_freq == slpc_max_freq) {
> + /* Server parts will have min/max clamped to RP0 */
> + if (slpc->min_is_rpmax) {
> + err = slpc_set_min_freq(slpc, slpc->min_freq);
> + if (err) {
> + pr_err("Unable to update min freq on server part");
> + return err;
> + }
>
> - if (slpc->min_freq == slpc->rp0_freq) {
> - pr_err("Min/Max are fused to the same value\n");
> - return -EINVAL;
> + } else {
> + pr_err("Min/Max are fused to the same value\n");
> + return -EINVAL;
Sorry but I am not following this else case here. Why are we saying min/max
are fused to the same value? In this case we can't do
"slpc_set_min_freq(slpc, slpc->min_freq)" ? That is, we can't change SLPC
min freq?
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index fdd895f73f9f..b7cdeec44bd3 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> @@ -263,6 +263,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
>
> slpc->max_freq_softlimit = 0;
> slpc->min_freq_softlimit = 0;
> + slpc->min_is_rpmax = false;
>
> slpc->boost_freq = 0;
> atomic_set(&slpc->num_waiters, 0);
> @@ -588,6 +589,32 @@ static int slpc_set_softlimits(struct intel_guc_slpc *slpc)
> return 0;
> }
>
> +static bool is_slpc_min_freq_rpmax(struct intel_guc_slpc *slpc)
> +{
> + int slpc_min_freq;
> +
> + if (intel_guc_slpc_get_min_freq(slpc, &slpc_min_freq))
> + return false;
I am wondering what happens if the above fails on server? Should we return
true or false on server and what are the consequences of returning false on
server?
Any case I think we should at least put a drm_err or something here just in
case this ever fails so we'll know something weird happened.
> +
> + if (slpc_min_freq == SLPC_MAX_FREQ_MHZ)
> + return true;
> + else
> + return false;
> +}
> +
> +static void update_server_min_softlimit(struct intel_guc_slpc *slpc)
> +{
> + /* For server parts, SLPC min will be at RPMax.
> + * Use min softlimit to clamp it to RP0 instead.
> + */
> + if (is_slpc_min_freq_rpmax(slpc) &&
> + !slpc->min_freq_softlimit) {
> + slpc->min_is_rpmax = true;
> + slpc->min_freq_softlimit = slpc->rp0_freq;
> + (slpc_to_gt(slpc))->defaults.min_freq = slpc->min_freq_softlimit;
> + }
> +}
> +
> static int slpc_use_fused_rp0(struct intel_guc_slpc *slpc)
> {
> /* Force SLPC to used platform rp0 */
> @@ -647,6 +674,9 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
>
> slpc_get_rp_values(slpc);
>
> + /* Handle the case where min=max=RPmax */
> + update_server_min_softlimit(slpc);
> +
> /* Set SLPC max limit to RP0 */
> ret = slpc_use_fused_rp0(slpc);
> if (unlikely(ret)) {
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
> index 82a98f78f96c..11975a31c9d0 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
> @@ -9,6 +9,8 @@
> #include "intel_guc_submission.h"
> #include "intel_guc_slpc_types.h"
>
> +#define SLPC_MAX_FREQ_MHZ 4250
This seems to be really a value (255 converted to freq) so seems ok to
intepret in MHz.
Thanks.
--
Ashutosh
next prev parent reply other threads:[~2022-10-20 22:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 18:30 [Intel-gfx] [PATCH v3] drm/i915/slpc: Use platform limits for min/max frequency Vinay Belgaumkar
2022-10-18 18:30 ` Vinay Belgaumkar
2022-10-18 19:21 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/slpc: Use platform limits for min/max frequency (rev3) Patchwork
2022-10-18 19:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-10-19 12:28 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-10-20 22:57 ` Dixit, Ashutosh [this message]
2022-10-22 1:38 ` [Intel-gfx] [PATCH v3] drm/i915/slpc: Use platform limits for min/max frequency Belgaumkar, Vinay
2022-10-22 5:26 ` Dixit, Ashutosh
2022-10-22 5:26 ` Dixit, Ashutosh
2022-10-24 19:38 ` Belgaumkar, Vinay
2022-10-24 19:38 ` Belgaumkar, Vinay
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=8735biqf22.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=nirmoy.das@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.