From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>,
John.C.Harrison@Intel.com, Intel-GFX@Lists.FreeDesktop.Org
Cc: DRI-Devel@Lists.FreeDesktop.Org, Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output
Date: Mon, 7 Nov 2022 09:33:55 +0000 [thread overview]
Message-ID: <fabaf9ee-f3fc-c18f-56b3-6d073618da41@linux.intel.com> (raw)
In-Reply-To: <6a4d1ac0-a1a0-e1d4-7d83-54b43d226371@intel.com>
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
>
>
> On 11/4/2022 10:25 AM, John.C.Harrison@Intel.com wrote:
>> From: John Harrison <John.C.Harrison@Intel.com>
>>
>> When trying to analyse bug reports from CI, customers, etc. it can be
>> difficult to work out exactly what is happening on which GT in a
>> multi-GT system. So add GT oriented debug/error message wrappers. If
>> used instead of the drm_ equivalents, you get the same output but with
>> a GT# prefix on it.
>>
>> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
>
> The only downside to this is that we'll print "GT0: " even on single-GT
> devices. We could introduce a gt->info.name and print that, so we could
> have it different per-platform, but IMO it's not worth the effort.
>
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>
> I think it might be worth getting an ack from one of the maintainers to
> make sure we're all aligned on transitioning to these new logging macro
> for gt code.
Idea is I think a very good one. First I would suggest standardising to lowercase GT in logs because:
$ grep "GT%" i915/ -r
$ grep "gt%" i915/ -r
i915/gt/intel_gt_sysfs.c: gt->i915->sysfs_gt, "gt%d", gt->info.id))
i915/gt/intel_gt_sysfs.c: "failed to initialize gt%d sysfs root\n", gt->info.id);
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6 sysfs files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RC6p sysfs files (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u RPS sysfs files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u punit_req_freq_mhz sysfs (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u throttle sysfs files (%pe)",
i915/gt/intel_gt_sysfs_pm.c: "failed to create gt%u media_perf_power_attrs sysfs (%pe)\n",
i915/gt/intel_gt_sysfs_pm.c: "failed to add gt%u rps defaults (%pe)\n",
i915/i915_driver.c: drm_err(>->i915->drm, "gt%d: intel_pcode_init failed %d\n", id, ret);
i915/i915_hwmon.c: snprintf(ddat_gt->name, sizeof(ddat_gt->name), "i915_gt%u", i);
Then there is a question of naming. Are we okay with GT_XXX or, do we want intel_gt_, or something completely different. I don't have a strong opinion at the moment so I'll add some more folks to Cc.
What I'd would like to see tried is to converting all of i915/gt within one kernel release so we don't have a mish-mash of log formats.
Regards,
Tvrtko
>> ---
>> drivers/gpu/drm/i915/gt/intel_gt.h | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
>> b/drivers/gpu/drm/i915/gt/intel_gt.h
>> index e0365d5562484..1e016fb0117a4 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
>> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
>> @@ -13,6 +13,21 @@
>> struct drm_i915_private;
>> struct drm_printer;
>> +#define GT_ERR(_gt, _fmt, ...) \
>> + drm_err(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
>> ##__VA_ARGS__)
>> +
>> +#define GT_WARN(_gt, _fmt, ...) \
>> + drm_warn(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
>> ##__VA_ARGS__)
>> +
>> +#define GT_NOTICE(_gt, _fmt, ...) \
>> + drm_notice(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
>> ##__VA_ARGS__)
>> +
>> +#define GT_INFO(_gt, _fmt, ...) \
>> + drm_info(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
>> ##__VA_ARGS__)
>> +
>> +#define GT_DBG(_gt, _fmt, ...) \
>> + drm_dbg(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
>> ##__VA_ARGS__)
>> +
>> #define GT_TRACE(gt, fmt, ...) do { \
>> const struct intel_gt *gt__ __maybe_unused = (gt); \
>> GEM_TRACE("%s " fmt, dev_name(gt__->i915->drm.dev), \
>
next prev parent reply other threads:[~2022-11-07 9:34 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 17:25 [Intel-gfx] [PATCH 0/2] Add GT oriented dmesg output John.C.Harrison
2022-11-04 17:25 ` [Intel-gfx] [PATCH 1/2] drm/i915/gt: " John.C.Harrison
2022-11-05 1:03 ` Ceraolo Spurio, Daniele
2022-11-07 9:33 ` Tvrtko Ursulin [this message]
2022-11-07 16:17 ` Tvrtko Ursulin
2022-11-07 19:14 ` John Harrison
2022-11-08 9:01 ` Tvrtko Ursulin
2022-11-08 20:15 ` John Harrison
2022-11-09 11:05 ` Tvrtko Ursulin
2022-11-09 17:46 ` John Harrison
2022-11-09 19:57 ` Michal Wajdeczko
2022-11-10 9:55 ` Tvrtko Ursulin
2022-11-10 10:35 ` Michal Wajdeczko
2022-11-15 10:23 ` Tvrtko Ursulin
2022-11-10 10:33 ` Jani Nikula
2022-11-14 22:10 ` John Harrison
2022-11-10 9:43 ` Tvrtko Ursulin
2022-11-14 22:14 ` John Harrison
2022-11-04 17:25 ` [Intel-gfx] [PATCH 2/2] drm/i915/uc: Update the gt/uc code to use GT_ERR and friends John.C.Harrison
2022-11-04 17:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add GT oriented dmesg output Patchwork
2022-11-04 18:04 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-11-05 9:24 ` [Intel-gfx] ✗ Fi.CI.IGT: 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=fabaf9ee-f3fc-c18f-56b3-6d073618da41@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=DRI-Devel@Lists.FreeDesktop.Org \
--cc=Intel-GFX@Lists.FreeDesktop.Org \
--cc=John.C.Harrison@Intel.com \
--cc=daniele.ceraolospurio@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