From: "Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
Riana Tauro <riana.tauro@intel.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v4] drm/xe/pmu: Add GT frequency events
Date: Tue, 25 Mar 2025 13:33:43 -0700 [thread overview]
Message-ID: <33ebfe1d-5ac5-4985-8c8d-c1996e5a6d14@intel.com> (raw)
In-Reply-To: <87jz8dhw0r.wl-ashutosh.dixit@intel.com>
On 3/25/2025 10:15 AM, Dixit, Ashutosh wrote:
> On Mon, 24 Mar 2025 19:37:32 -0700, Belgaumkar, Vinay wrote:
> Hi Vinay,
>
>> On 3/24/2025 5:18 PM, Dixit, Ashutosh wrote:
>>> On Mon, 24 Mar 2025 16:24:02 -0700, Vinay Belgaumkar wrote:
>>>> @@ -266,11 +274,24 @@ static u64 __xe_pmu_event_read(struct perf_event *event)
>>>> case XE_PMU_EVENT_ENGINE_ACTIVE_TICKS:
>>>> case XE_PMU_EVENT_ENGINE_TOTAL_TICKS:
>>>> return read_engine_events(gt, event);
>>>> + case XE_PMU_EVENT_GT_ACTUAL_FREQUENCY:
>>>> + return xe_guc_pc_get_act_freq(>->uc.guc.pc);
>>>> + case XE_PMU_EVENT_GT_REQUESTED_FREQUENCY:
>>>> + if (!xe_guc_pc_get_cur_freq(>->uc.guc.pc, &cur_gt_freq))
>>> This is unconditionally taking the forcewake and waking the card up just to
>>> get the sample. Do we really want to do that?
>>>
>>> So if we don't do that, both the actual and requested freq will be 0 if gt
>>> is in C6.
>> For actual frequency, the register(0xc60) does not belong to any fw domain -
>>
>> GEN_FW_RANGE(0xc00, 0xfff, 0),
>>
>> HW will report 0 when GT is in C6.
> Yes, no issue about act_freq, see commit 22009b6dad66. I was referring only
> to requested freq.
>
>> The requested freq register is a
>> shadowed register (0xa008), so that will not accrue fwake either.
>>
>> static const struct i915_range mtl_shadowed_regs[] = {
>> { .start = 0x2030, .end = 0x2030 },
>> { .start = 0x2510, .end = 0x2550 },
>> { .start = 0xA008, .end = 0xA00C },
> So this still doesn't make sense because:
>
> 1. The fact is that xe_guc_pc_get_cur_freq() *is* taking forcewake
> 2. And that is in accord with the following comment in i915/intel_uncore.c
>
> * Shadowing only applies to writes; forcewake
> * must still be acquired when reading from registers in these ranges.
>
> Also see intel_rps_read_punit_req() which is called from i915 PMU
> (frequency_sample()) and uses with_intel_runtime_pm_if_in_use(), so we'd
> need to do use the equivalent in xe.
Hi Ashutosh,
As part of a previous decision, in the Xe PMU implementation, we are
doing a runtime_get() during pmu_init for all PMU sessions. So, device
is going to be awake anyways. In this case, it does not make sense to
just read the register without a fwake.
Thanks,
Vinay.
>
> Thanks.
> --
> Ashutosh
next prev parent reply other threads:[~2025-03-25 20:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-24 23:24 [PATCH v4] drm/xe/pmu: Add GT frequency events Vinay Belgaumkar
2025-03-25 0:18 ` Dixit, Ashutosh
2025-03-25 2:37 ` Belgaumkar, Vinay
2025-03-25 17:15 ` Dixit, Ashutosh
2025-03-25 20:33 ` Belgaumkar, Vinay [this message]
2025-03-25 21:53 ` Dixit, Ashutosh
2025-03-25 22:01 ` Belgaumkar, Vinay
2025-03-25 22:45 ` Dixit, Ashutosh
2025-03-25 23:02 ` Belgaumkar, Vinay
2025-03-26 4:09 ` Lucas De Marchi
2025-03-26 4:14 ` Lucas De Marchi
2025-03-26 15:02 ` Dixit, Ashutosh
2025-03-26 15:34 ` Lucas De Marchi
2025-03-26 22:02 ` Belgaumkar, Vinay
2025-03-26 22:38 ` Dixit, Ashutosh
2025-03-25 0:29 ` ✓ CI.Patch_applied: success for drm/xe/pmu: Add GT frequency events (rev6) Patchwork
2025-03-25 0:29 ` ✗ CI.checkpatch: warning " Patchwork
2025-03-25 0:30 ` ✓ CI.KUnit: success " Patchwork
2025-03-25 0:47 ` ✓ CI.Build: " Patchwork
2025-03-25 0:49 ` ✓ CI.Hooks: " Patchwork
2025-03-25 0:50 ` ✓ CI.checksparse: " Patchwork
2025-03-25 1:11 ` ✓ Xe.CI.BAT: " Patchwork
2025-03-25 6:04 ` ✗ Xe.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=33ebfe1d-5ac5-4985-8c8d-c1996e5a6d14@intel.com \
--to=vinay.belgaumkar@intel.com \
--cc=ashutosh.dixit@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=riana.tauro@intel.com \
--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