Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Restore efficient freq earlier
Date: Fri, 21 Jul 2023 15:08:55 -0700	[thread overview]
Message-ID: <d3433b3c-bed2-c42f-7ad7-ceb8e7afc79d@intel.com> (raw)
In-Reply-To: <ZLr3XJNb2JdXcyvp@intel.com>


On 7/21/2023 2:23 PM, Rodrigo Vivi wrote:
> On Fri, Jul 21, 2023 at 01:44:34PM -0700, Belgaumkar, Vinay wrote:
>> On 7/21/2023 1:41 PM, Rodrigo Vivi wrote:
>>> On Fri, Jul 21, 2023 at 11:03:49AM -0700, Vinay Belgaumkar wrote:
>>>> This should be done before the soft min/max frequencies are restored.
>>>> When we disable the "Ignore efficient frequency" flag, GuC does not
>>>> actually bring the requested freq down to RPn.
>>>>
>>>> Specifically, this scenario-
>>>>
>>>> - ignore efficient freq set to true
>>>> - reduce min to RPn (from efficient)
>>>> - suspend
>>>> - resume (includes GuC load, restore soft min/max, restore efficient freq)
>>>> - validate min freq has been resored to RPn
>>>>
>>>> This will fail if we didn't first restore(disable, in this case) efficient
>>>> freq flag before setting the soft min frequency.
>>> that's strange. so guc is returning the rpe when we request the min freq
>>> during the soft config?
>>>
>>> we could alternatively change the soft config to actually get the min
>>> and not be tricked by this.
>>>
>>> But also the patch below doesn't hurt.
>>>
>>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> (Although I'm still curious and want to understand exactly why
>>> the soft min gets messed up when we don't tell guc to ignore the
>>> efficient freq beforehand. Please help me to understand.)
>> The soft min does not get messed up, but GuC keeps requesting RPe even after
>> disabling efficient freq. (unless we manually set min freq to RPn AFTER
>> disabling efficient).
> so it looks to me that the right solution would be to ensure that everytime
> that we disable the efficient freq we make sure to also set the mim freq to RPn,
> no?!

Hmm, may not be applicable every time. What if someone disables 
efficient frequency while running a workload or with frequency fixed to 
800, for example?

Thanks,

Vinay.

>
>> Thanks,
>>
>> Vinay.
>>
>>>
>>>> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736
>>>> Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq")
>>>> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 6 +++---
>>>>    1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> 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 ee9f83af7cf6..f16dff7c3185 100644
>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
>>>> @@ -743,6 +743,9 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
>>>>    	intel_guc_pm_intrmsk_enable(slpc_to_gt(slpc));
>>>> +	/* Set cached value of ignore efficient freq */
>>>> +	intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
>>>> +
>>>>    	slpc_get_rp_values(slpc);
>>>>    	/* Handle the case where min=max=RPmax */
>>>> @@ -765,9 +768,6 @@ int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
>>>>    	/* Set cached media freq ratio mode */
>>>>    	intel_guc_slpc_set_media_ratio_mode(slpc, slpc->media_ratio_mode);
>>>> -	/* Set cached value of ignore efficient freq */
>>>> -	intel_guc_slpc_set_ignore_eff_freq(slpc, slpc->ignore_eff_freq);
>>>> -
>>>>    	return 0;
>>>>    }
>>>> -- 
>>>> 2.38.1
>>>>

  reply	other threads:[~2023-07-21 22:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-21 18:03 [Intel-gfx] [PATCH] drm/i915/guc/slpc: Restore efficient freq earlier Vinay Belgaumkar
2023-07-21 19:33 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2023-07-21 20:41 ` [Intel-gfx] [PATCH] " Rodrigo Vivi
2023-07-21 20:44   ` Belgaumkar, Vinay
2023-07-21 21:23     ` Rodrigo Vivi
2023-07-21 22:08       ` Belgaumkar, Vinay [this message]
2023-07-21 22:21         ` Belgaumkar, Vinay
2023-07-22  0:15 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for " Patchwork

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=d3433b3c-bed2-c42f-7ad7-ceb8e7afc79d@intel.com \
    --to=vinay.belgaumkar@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@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