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:21:41 -0700	[thread overview]
Message-ID: <d425e31f-6b86-3bbf-20bb-dece6f749fa1@intel.com> (raw)
In-Reply-To: <d3433b3c-bed2-c42f-7ad7-ceb8e7afc79d@intel.com>


On 7/21/2023 3:08 PM, Belgaumkar, Vinay wrote:
>
> 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?

I'll take that back, it should not matter. GuC will not change it's 
request just because we switched min lower. I will resend the patch with 
the min setting as well.

Thanks,

Vinay.

>
> 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:21 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
2023-07-21 22:21         ` Belgaumkar, Vinay [this message]
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=d425e31f-6b86-3bbf-20bb-dece6f749fa1@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