From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "tvrtko.ursulin@linux.intel.com" <tvrtko.ursulin@linux.intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add error-capture init warnings when needed
Date: Mon, 17 Oct 2022 17:46:24 +0000 [thread overview]
Message-ID: <0c41d33552a0cc52c3835be99ce2e0e50a9084af.camel@intel.com> (raw)
In-Reply-To: <e02ac836-89f4-1734-eacc-73f49ecda323@linux.intel.com>
On Mon, 2022-10-17 at 09:42 +0100, Tvrtko Ursulin wrote:
> On 15/10/2022 04:59, Alan Previn wrote:
> > If GuC is being used and we initialized GuC-error-capture,
> > we need to be warning if we don't provide an error-capture
> > register list in the firmware ADS, for valid GT engines.
> > A warning makes sense as this would impact debugability
> > without realizing why a reglist wasn't retrieved and reported
> > by GuC.>
> > However, depending on the platform, we might have certain
> > engines that have a register list for engine instance error state
> > but not for engine class. Thus, add a check only to warn if the
> > register list was non existent vs an empty list (use the
> > empty lists to skip the warning).
> >
> > Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
> > ---
> > .../gpu/drm/i915/gt/uc/intel_guc_capture.c | 55 ++++++++++++++++++-
> > 1 file changed, 53 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > index 8f1165146013..290c1e1343dd 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > @@ -419,6 +419,44 @@ guc_capture_get_device_reglist(struct intel_guc *guc)
> > return default_lists;
> > }
> >
> > +static const char *
> > +__stringify_type(u32 type)
> > +{
> > + switch (type) {
> > + case GUC_CAPTURE_LIST_TYPE_GLOBAL:
> > + return "Global";
> > + case GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS:
> > + return "Class";
> > + case GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE:
> > + return "Instance";
> > + default:
> > + return "unknown";
> > + }
> > +
> > + return "";
>
> What's the point of these returns? Gcc complains about not returning a type from const char * return function?
>
Sorry i am not sure I saw any complain for Gcc. If you are referring to "" then i can re-rev without the default and
just let the path outside return the unknown. Is that what you are referring to?
> > +}
> > +
> > +static const char *
> > +__stringify_engclass(u32 class)
> > +{
> > + switch (class) {
> > + case GUC_RENDER_CLASS:
> > + return "Render";
> > + case GUC_VIDEO_CLASS:
> > + return "Video";
> > + case GUC_VIDEOENHANCE_CLASS:
> > + return "VideoEnhance";
> > + case GUC_BLITTER_CLASS:
> > + return "Blitter";
> > + case GUC_COMPUTE_CLASS:
> > + return "Compute";
> > + default:
> > + return "unknown";
> > + }
> > +
> > + return "";
> > +}
> > +
> > static int
> > guc_capture_list_init(struct intel_guc *guc, u32 owner, u32 type, u32 classid,
> > struct guc_mmio_reg *ptr, u16 num_entries)
> > @@ -487,19 +525,32 @@ intel_guc_capture_getlistsize(struct intel_guc *guc, u32 owner, u32 type, u32 cl
> > size_t *size)
> > {
> > struct intel_guc_state_capture *gc = guc->capture;
> > + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> > struct __guc_capture_ads_cache *cache = &gc->ads_cache[owner][type][classid];
> > int num_regs;
> >
> > - if (!gc->reglists)
> > + if (!gc->reglists) {
> > + drm_warn(&i915->drm, "GuC-capture: No reglist on this device\n");
> > return -ENODEV;
> > + }
> >
> > if (cache->is_valid) {
> > *size = cache->size;
> > return cache->status;
> > }
> >
> > + if (!guc_capture_get_one_list(gc->reglists, owner, type, classid)) {
> > + if (owner == GUC_CAPTURE_LIST_INDEX_PF && type == GUC_CAPTURE_LIST_TYPE_GLOBAL)
> > + drm_warn(&i915->drm, "GuC-capture: missing reglist type-Global\n");
> > + if (owner == GUC_CAPTURE_LIST_INDEX_PF)
>
> GUC_CAPTURE_LIST_INDEX_PF could be made once on the enclosing if statement?
Sure - will do.
>
> Btw what's with the PF and VF (cover letter) references while SRIOV does not exists upstream?
To maintain a scalable code flow across both the ADS code and guc-error-capture code, we do have to skip over this enum
else we'll encounter lots of warnings about missing VF-reglist support (which we cant check for since we dont even have
support - i.e we dont even have a "is not supported" check) but the GuC firmware ADS buffer allocation includes an entry
for VFs so we have to skip over it. This is the cleanest way i can think of without impacting other code areas and also
while adding the ability to warn when its important.
> > + drm_warn(&i915->drm, "GuC-capture: missing regiist type(%d)-%s : "
>
> reglist
thanks - will fix
>
> > + "%s(%d)-Engine\n", type, __stringify_type(type),
> > + __stringify_engclass(classid), classid);
>
> One details to consider from Documentation/process/coding-style.rst
> """
> However, never break user-visible strings such as printk messages because that breaks the ability to grep for them.
> """
>
I totally agree with you but i cant find a way to keep totally grep-able way without creating a whole set of error
strings for the various list-types, list-owners and class-types. However i did ensure the first part of the message
is grep-able : "GuC-capture: missing reglist type". Do you an alternative proposal?
> Also commit message you can aim to wrap at 75 chars as per submitting-patches.rst.
>
> > + return -ENODATA;
>
> Is this a new exit condition or the thing would exit on the !num_regs check below anyway? Just wondering if the series is only about logging changes or there is more to it.
Its no different from previous behavior - and yes its about logging the missing reg lists for hw that needs it as we are
missing this for DG2 we we didn't notice (we did a previous revert to remove these warnings but that time the warnings
was too verbose - even complaining for the intentional empty lists and for VF cases that isnt supported).
>
> > + }
> > +
> > num_regs = guc_cap_list_num_regs(gc, owner, type, classid);
> > - if (!num_regs)
> > + if (!num_regs) /* intentional empty lists can exist depending on hw config */
> > return -ENODATA;
> >
> > *size = PAGE_ALIGN((sizeof(struct guc_debug_capture_list)) +
>
> Regards,
>
> Tvrtko
next prev parent reply other threads:[~2022-10-17 17:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-15 3:59 [Intel-gfx] [PATCH 0/2] drm/i915/guc: Add GuC-Error-Capture-Init coverage of new engine types Alan Previn
2022-10-15 3:59 ` [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add error-capture init warnings when needed Alan Previn
2022-10-17 8:42 ` Tvrtko Ursulin
2022-10-17 17:46 ` Teres Alexis, Alan Previn [this message]
2022-10-18 8:00 ` Tvrtko Ursulin
2022-10-19 5:14 ` Teres Alexis, Alan Previn
2022-10-19 5:28 ` Teres Alexis, Alan Previn
2022-10-17 19:33 ` John Harrison
2022-10-17 23:36 ` Teres Alexis, Alan Previn
2022-10-18 0:15 ` John Harrison
2022-10-15 3:59 ` [Intel-gfx] [PATCH 2/2] drm/i915/guc: Add compute reglist for GuC error capture Alan Previn
2022-10-17 8:43 ` Tvrtko Ursulin
2022-10-17 17:32 ` Teres Alexis, Alan Previn
2022-10-18 8:04 ` Tvrtko Ursulin
2022-10-15 4:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Add GuC-Error-Capture-Init coverage of new engine types Patchwork
2022-10-15 6:24 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=0c41d33552a0cc52c3835be99ce2e0e50a9084af.camel@intel.com \
--to=alan.previn.teres.alexis@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@linux.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