From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "José Roberto de Souza" <jose.souza@intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 7/9] drm/xe: Print more device information in devcoredump
Date: Mon, 22 Jan 2024 15:18:08 -0500 [thread overview]
Message-ID: <Za7NgM_B_nBIbTXL@intel.com> (raw)
In-Reply-To: <20240122170445.108856-7-jose.souza@intel.com>
On Mon, Jan 22, 2024 at 09:04:43AM -0800, José Roberto de Souza wrote:
> To properly decode batch buffer Mesa tools needs to know what
> platform is this one, for now we can do that with PCI id but
> already making it future proof by also printing GTs GMD version.
>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Maarten Lankhorst <dev@lankhorst.se>
> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> ---
> drivers/gpu/drm/xe/xe_devcoredump.c | 2 ++
> drivers/gpu/drm/xe/xe_device.c | 20 ++++++++++++++++++++
> drivers/gpu/drm/xe/xe_device.h | 2 ++
> 3 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
> index a0e3732440ab5..43b66ca710f85 100644
> --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> @@ -63,6 +63,7 @@ static ssize_t xe_devcoredump_read(char *buffer, loff_t offset,
> size_t count, void *data, size_t datalen)
> {
> struct xe_devcoredump *coredump = data;
> + struct xe_device *xe = devcoredump_to_xe_device(coredump);
> struct xe_devcoredump_snapshot *ss;
> struct drm_printer p;
> struct drm_print_iterator iter;
> @@ -89,6 +90,7 @@ static ssize_t xe_devcoredump_read(char *buffer, loff_t offset,
> drm_printf(&p, "Snapshot time: %lld.%09ld\n", ts.tv_sec, ts.tv_nsec);
> ts = ktime_to_timespec64(ss->boot_time);
> drm_printf(&p, "Uptime: %lld.%09ld\n", ts.tv_sec, ts.tv_nsec);
> + xe_device_snapshot_print(xe, &p);
>
> drm_printf(&p, "\n**** GuC CT ****\n");
> xe_guc_ct_snapshot_print(coredump->snapshot.ct, &p);
> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index b4cdcf1b2081a..e0136e7d5ae52 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -742,3 +742,23 @@ u64 xe_device_uncanonicalize_addr(struct xe_device *xe, u64 address)
> {
> return address & GENMASK_ULL(highest_address_bit_get(xe), 0);
> }
> +
> +void xe_device_snapshot_print(struct xe_device *xe, struct drm_printer *p)
> +{
> + struct xe_gt *gt;
> + u8 id;
> +
> + drm_printf(p, "PCI ID: 0x%04x\n", xe->info.devid);
> + drm_printf(p, "PCI revision: 0x%02x\n", xe->info.revid);
> +
> + for_each_gt(gt, xe, id) {
> + drm_printf(p, "GT id: %u\n", id);
> + drm_printf(p, "\tType: %s\n",
> + gt->info.type == XE_GT_TYPE_MAIN ? "main" : "media");
> + drm_printf(p, "\tIP ver: %u.%u.%u\n",
> + REG_FIELD_GET(GMD_ID_ARCH_MASK, gt->info.gmdid),
> + REG_FIELD_GET(GMD_ID_RELEASE_MASK, gt->info.gmdid),
> + REG_FIELD_GET(GMD_ID_REVID, gt->info.gmdid));
> + drm_printf(p, "\tCS timestamp frequency: %u\n", gt->info.reference_clock);
I don't like much the word 'frequency' along with this because of the
traditional confusion with the main running GT frequency.
Imho any combination with the words: timestamp reference crystal clock would
be better.
But I will leave the decision to you...
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
regardless
> + }
> +}
> diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
> index 781a1aa164ecf..7df7cce218770 100644
> --- a/drivers/gpu/drm/xe/xe_device.h
> +++ b/drivers/gpu/drm/xe/xe_device.h
> @@ -183,4 +183,6 @@ u32 xe_device_ccs_bytes(struct xe_device *xe, u64 size);
> u64 xe_device_canonicalize_addr(struct xe_device *xe, u64 address);
> u64 xe_device_uncanonicalize_addr(struct xe_device *xe, u64 address);
>
> +void xe_device_snapshot_print(struct xe_device *xe, struct drm_printer *p);
> +
> #endif
> --
> 2.43.0
>
next prev parent reply other threads:[~2024-01-22 20:18 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 17:04 [PATCH 1/9] drm/xe: Remove double new line in devcoredump José Roberto de Souza
2024-01-22 17:04 ` [PATCH 2/9] drm/xe: Change devcoredump functions parameters to xe_sched_job José Roberto de Souza
2024-01-22 18:39 ` Summers, Stuart
2024-01-22 17:04 ` [PATCH 3/9] drm/xe: Add functions to convert regular address to canonical address and back José Roberto de Souza
2024-01-22 18:38 ` Summers, Stuart
2024-01-22 18:43 ` Souza, Jose
2024-01-24 15:16 ` Summers, Stuart
2024-01-24 15:20 ` Souza, Jose
2024-01-29 17:54 ` Summers, Stuart
2024-01-23 17:48 ` Jani Nikula
2024-01-22 17:04 ` [PATCH 4/9] drm/xe: Add batch buffer addresses to devcoredump José Roberto de Souza
2024-01-22 20:13 ` Rodrigo Vivi
2024-01-22 17:04 ` [PATCH 5/9] drm/xe: Nuke xe from xe_devcoredump José Roberto de Souza
2024-01-22 20:11 ` Rodrigo Vivi
2024-01-22 20:26 ` Souza, Jose
2024-01-22 20:40 ` Rodrigo Vivi
2024-01-22 17:04 ` [PATCH 6/9] drm/xe: Stash GMD_ID value in xe_gt José Roberto de Souza
2024-01-22 17:04 ` [PATCH 7/9] drm/xe: Print more device information in devcoredump José Roberto de Souza
2024-01-22 20:18 ` Rodrigo Vivi [this message]
2024-01-22 21:12 ` Souza, Jose
2024-01-22 17:04 ` [PATCH 8/9] drm/xe: Print registers spread in 2 u32 as u64 José Roberto de Souza
2024-01-22 20:14 ` Rodrigo Vivi
2024-01-22 17:04 ` [PATCH 9/9] drm/xe: Remove addional spaces in devcoredump HW Engines section José Roberto de Souza
2024-01-22 20:18 ` Rodrigo Vivi
2024-01-22 17:32 ` ✓ CI.Patch_applied: success for series starting with [1/9] drm/xe: Remove double new line in devcoredump Patchwork
2024-01-22 17:32 ` ✗ CI.checkpatch: warning " Patchwork
2024-01-22 17:33 ` ✓ CI.KUnit: success " Patchwork
2024-01-22 17:40 ` ✓ CI.Build: " Patchwork
2024-01-22 17:41 ` ✗ CI.Hooks: failure " Patchwork
2024-01-22 17:42 ` ✓ CI.checksparse: success " Patchwork
2024-01-22 18:05 ` ✓ CI.BAT: " Patchwork
2024-01-22 18:28 ` [PATCH 1/9] " Summers, Stuart
2024-01-22 18:40 ` Souza, Jose
2024-01-22 20:20 ` Rodrigo Vivi
2024-01-24 15:17 ` Summers, Stuart
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=Za7NgM_B_nBIbTXL@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=dev@lankhorst.se \
--cc=intel-xe@lists.freedesktop.org \
--cc=jose.souza@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.