From: John Harrison <john.c.harrison@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: <Intel-Xe@lists.freedesktop.org>,
Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH v2 1/2] drm/xe/guc: Capture all available bits of GuC timestamp
Date: Thu, 24 Oct 2024 14:27:59 -0700 [thread overview]
Message-ID: <3bcdbf60-0de9-4873-b6e4-836f8e2e3816@intel.com> (raw)
In-Reply-To: <20241024211229.GN5725@mdroper-desk1.amr.corp.intel.com>
On 10/24/2024 14:12, Matt Roper wrote:
> On Wed, Oct 23, 2024 at 05:25:53PM -0700, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> The extra bits are not hugely useful because the GuC log only uses
>> 32bit time stamps. But they exist so might as well provide them.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
>> ---
>> drivers/gpu/drm/xe/regs/xe_guc_regs.h | 3 ++-
>> drivers/gpu/drm/xe/xe_guc_log.c | 6 +++---
>> drivers/gpu/drm/xe/xe_guc_log_types.h | 2 +-
>> 3 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/regs/xe_guc_regs.h b/drivers/gpu/drm/xe/regs/xe_guc_regs.h
>> index b27b73680c12..2118f7dec287 100644
>> --- a/drivers/gpu/drm/xe/regs/xe_guc_regs.h
>> +++ b/drivers/gpu/drm/xe/regs/xe_guc_regs.h
>> @@ -84,7 +84,8 @@
>> #define HUC_LOADING_AGENT_GUC REG_BIT(1)
>> #define GUC_WOPCM_OFFSET_VALID REG_BIT(0)
>> #define GUC_MAX_IDLE_COUNT XE_REG(0xc3e4)
>> -#define GUC_PMTIMESTAMP XE_REG(0xc3e8)
>> +#define GUC_PMTIMESTAMP_LO XE_REG(0xc3e8)
>> +#define GUC_PMTIMESTAMP_HI XE_REG(0xc3ec)
> Do we actually need this change if we're not using _HI directly
> anywhere?
Define need?
It makes it obvious that the register read is correct in doing a 64_2x32
operation. Otherwise, it can look like a bug that we are reading beyond
the valid register definition. So while it might not be required from a
compilation point of view, I think it is useful from a code readability
point of view.
John.
>
>
> Matt
>
>>
>> #define GUC_SEND_INTERRUPT XE_REG(0xc4c8)
>> #define GUC_SEND_TRIGGER REG_BIT(0)
>> diff --git a/drivers/gpu/drm/xe/xe_guc_log.c b/drivers/gpu/drm/xe/xe_guc_log.c
>> index fead96216243..df4cfb698cdb 100644
>> --- a/drivers/gpu/drm/xe/xe_guc_log.c
>> +++ b/drivers/gpu/drm/xe/xe_guc_log.c
>> @@ -171,9 +171,9 @@ struct xe_guc_log_snapshot *xe_guc_log_snapshot_capture(struct xe_guc_log *log,
>>
>> fw_ref = xe_force_wake_get(gt_to_fw(gt), XE_FW_GT);
>> if (!fw_ref) {
>> - snapshot->stamp = ~0;
>> + snapshot->stamp = ~0ULL;
>> } else {
>> - snapshot->stamp = xe_mmio_read32(>->mmio, GUC_PMTIMESTAMP);
>> + snapshot->stamp = xe_mmio_read64_2x32(>->mmio, GUC_PMTIMESTAMP_LO);
>> xe_force_wake_put(gt_to_fw(gt), fw_ref);
>> }
>> snapshot->ktime = ktime_get_boottime_ns();
>> @@ -205,7 +205,7 @@ void xe_guc_log_snapshot_print(struct xe_guc_log_snapshot *snapshot, struct drm_
>> snapshot->ver_found.major, snapshot->ver_found.minor, snapshot->ver_found.patch,
>> snapshot->ver_want.major, snapshot->ver_want.minor, snapshot->ver_want.patch);
>> drm_printf(p, "Kernel timestamp: 0x%08llX [%llu]\n", snapshot->ktime, snapshot->ktime);
>> - drm_printf(p, "GuC timestamp: 0x%08X [%u]\n", snapshot->stamp, snapshot->stamp);
>> + drm_printf(p, "GuC timestamp: 0x%08llX [%llu]\n", snapshot->stamp, snapshot->stamp);
>> drm_printf(p, "Log level: %u\n", snapshot->level);
>>
>> remain = snapshot->size;
>> diff --git a/drivers/gpu/drm/xe/xe_guc_log_types.h b/drivers/gpu/drm/xe/xe_guc_log_types.h
>> index 4d57f8322efc..b3d5c72ac752 100644
>> --- a/drivers/gpu/drm/xe/xe_guc_log_types.h
>> +++ b/drivers/gpu/drm/xe/xe_guc_log_types.h
>> @@ -27,7 +27,7 @@ struct xe_guc_log_snapshot {
>> /** @ktime: Kernel time the snapshot was taken */
>> u64 ktime;
>> /** @stamp: GuC timestamp at which the snapshot was taken */
>> - u32 stamp;
>> + u64 stamp;
>> /** @level: GuC log verbosity level */
>> u32 level;
>> /** @ver_found: GuC firmware version */
>> --
>> 2.47.0
>>
next prev parent reply other threads:[~2024-10-24 21:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 0:25 [PATCH v2 0/2] drm/xe/guc: Improvements to GuC debugfs info John.C.Harrison
2024-10-24 0:25 ` [PATCH v2 1/2] drm/xe/guc: Capture all available bits of GuC timestamp John.C.Harrison
2024-10-24 21:12 ` Matt Roper
2024-10-24 21:27 ` John Harrison [this message]
2024-10-24 0:25 ` [PATCH v2 2/2] drm/xe/guc: Separate full CTB content from guc_info debugfs John.C.Harrison
2024-10-24 2:56 ` Matthew Brost
2024-10-24 18:41 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improvements to GuC debugfs info (rev2) Patchwork
2024-10-24 18:42 ` ✓ CI.checkpatch: " Patchwork
2024-10-24 18:43 ` ✓ CI.KUnit: " Patchwork
2024-10-24 18:54 ` ✓ CI.Build: " Patchwork
2024-10-24 18:57 ` ✓ CI.Hooks: " Patchwork
2024-10-24 18:58 ` ✓ CI.checksparse: " Patchwork
2024-10-24 19:24 ` ✗ CI.BAT: failure " Patchwork
2024-10-25 18:52 ` ✓ CI.Patch_applied: success for drm/xe/guc: Improvements to GuC debugfs info (rev3) Patchwork
2024-10-25 18:52 ` ✓ CI.checkpatch: " Patchwork
2024-10-25 18:54 ` ✓ CI.KUnit: " Patchwork
2024-10-25 19:05 ` ✓ CI.Build: " Patchwork
2024-10-25 19:07 ` ✓ CI.Hooks: " Patchwork
2024-10-25 19:09 ` ✓ CI.checksparse: " Patchwork
2024-10-25 19:32 ` ✓ CI.BAT: " Patchwork
2024-10-26 0:29 ` ✗ CI.FULL: failure for drm/xe/guc: Improvements to GuC debugfs info (rev2) Patchwork
2024-10-27 8:37 ` ✗ CI.FULL: failure for drm/xe/guc: Improvements to GuC debugfs info (rev3) Patchwork
2024-10-29 11:45 ` 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=3bcdbf60-0de9-4873-b6e4-836f8e2e3816@intel.com \
--to=john.c.harrison@intel.com \
--cc=Intel-Xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=matthew.d.roper@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