Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Anirban, Sk" <sk.anirban@intel.com>
To: Riana Tauro <riana.tauro@intel.com>,
	"Nilawar, Badal" <badal.nilawar@intel.com>,
	<intel-gfx@lists.freedesktop.org>
Cc: <anshuman.gupta@intel.com>, <karthik.poosa@intel.com>
Subject: Re: [PATCH v2] drm/i915/selftests: Correct frequency handling in RPS power measurement
Date: Mon, 13 Jan 2025 12:54:24 +0530	[thread overview]
Message-ID: <b356f17e-9fc7-42d2-9198-66b65a330b69@intel.com> (raw)
In-Reply-To: <71aaad10-abe8-4642-90fb-1a5c19dd3231@intel.com>




On 13-01-2025 12:38, Riana Tauro wrote:
> Hi Anirban
>
> On 1/10/2025 8:42 PM, Anirban, Sk wrote:
>>
>>
>>
>> On 09-01-2025 16:45, Nilawar, Badal wrote:
>>>
>>>
>>> On 09-01-2025 15:50, Nilawar, Badal wrote:
>>>>
>>>>
>>>> On 09-01-2025 15:00, sk.anirban@intel.com wrote:
>>>>> From: Sk Anirban<sk.anirban@intel.com>
>>>>>
>>>>> Fix the frequency calculation by ensuring it is adjusted
>>>>> only once during power measurement. Update live_rps_power test
>>>>> to use the correct frequency values for logging and comparison.
>>>>>
>>>>> v2:
>>>>>    - Improved frequency logging (Riana)
>>>>>
>>>>> Signed-off-by: Sk Anirban<sk.anirban@intel.com>
>>>>> Reviewed-by: Riana Tauro<riana.tauro@intel.com>
>>>>> ---
>>>>>   drivers/gpu/drm/i915/gt/selftest_rps.c | 11 ++++++-----
>>>>>   1 file changed, 6 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c b/drivers/gpu/ 
>>>>> drm/i915/gt/selftest_rps.c
>>>>> index c207a4fb03bf..e515d7eb628a 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/selftest_rps.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
>>>>> @@ -1126,6 +1126,7 @@ static u64 measure_power_at(struct intel_rps 
>>>>> *rps, int *freq)
>>>>>   {
>>>>>       *freq = rps_set_check(rps, *freq);
>>>>>       msleep(100);
>>>>> +    *freq = intel_gpu_freq(rps, *freq);
>>>> I am seeingrps_set_check will wait till act freq become desired 
>>>> freq, in case of timeout act freq could be different. I think it 
>>>> would be good to check freq returned by rps_set_check is expected 
>>>> freq if not then read freq again after msleep.
>>>
>>> Please ignore above comments, I got your code. You are applying freq 
>>> multiplier before passing to measure_power. While this approach 
>>> works fine, I recommend fixing measure_power() by using read_cagf() 
>>> instead of intel_rps_read_actual_frequency().
>>> Add Fixes: ac4e8560248f ("drm/i915/selftests: Add helper function 
>>> measure_power") in commit message.
>>>
>>> Regards,
>>> Badal
>>>
>> The measure_power() function is being used by slpc also, as slpc is 
>> not passing the raw frequency it may cause issue. So the plan is to 
>> create independent function to measure power for slpc, and for rps I 
>> will be using read_cagf() to calculate the avg.
>
> Are you planning to re-work this patch? In that case use read_cagf for 
> SLPC as well, wouldn't that work?
Yes, I'm modifying the patch to use read_cagf for rps and for slpc I am 
using an independent function to measure power using 
intel_rps_read_actual_frequency and that will internally call read_cagf.
>>
>> Regards,
>> Anirban
>>>
>>>> Regards, Badal
>>>>
>>>>>       return measure_power(rps, freq);
>>>>>   }
>>>>> @@ -1202,13 +1203,13 @@ int live_rps_power(void *arg)
>>>>>           pr_info("%s: min:%llumW @ %uMHz, max:%llumW @ %uMHz\n",
>>>>>               engine->name,
>>>>> -            min.power, intel_gpu_freq(rps, min.freq),
>>>>> -            max.power, intel_gpu_freq(rps, max.freq));
>>>>> +            min.power, min.freq,
>>>>> +            max.power, max.freq);
>>>>>           if (10 * min.freq >= 9 * max.freq) {
>>>>> -            pr_notice("Could not control frequency, ran at [%d: 
>>>>> %uMHz, %d:%uMhz]\n",
>>>>> -                  min.freq, intel_gpu_freq(rps, min.freq),
>>>>> -                  max.freq, intel_gpu_freq(rps, max.freq));
>>>>> +            pr_notice("Could not control frequency, ran at 
>>>>> [%uMHz, %uMhz]\n",
>>>>> +                  min.freq,
>>>>> +                  max.freq);
>>>>>               continue;
>>>>>           }
>>
>


  reply	other threads:[~2025-01-13  7:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-09  9:30 [PATCH v2] drm/i915/selftests: Correct frequency handling in RPS power measurement sk.anirban
2025-01-09 10:20 ` Nilawar, Badal
2025-01-09 11:15   ` Nilawar, Badal
2025-01-10 15:12     ` Anirban, Sk
2025-01-13  7:08       ` Riana Tauro
2025-01-13  7:24         ` Anirban, Sk [this message]
2025-01-09 10:59 ` ✓ i915.CI.BAT: success for drm/i915/selftests: Correct frequency handling in RPS power measurement (rev2) Patchwork
2025-01-11 20:48 ` ✗ i915.CI.Full: failure " 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=b356f17e-9fc7-42d2-9198-66b65a330b69@intel.com \
    --to=sk.anirban@intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=karthik.poosa@intel.com \
    --cc=riana.tauro@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