[PATCH v6 3/6] drm/xe/guc: Split engine state print between xe_hw_engine vs xe_guc_capture

[Teres Alexis, Alan Previn]

On Fri, 2025-01-31 at 10:55 -0800, Teres Alexis, Alan Previn wrote:
> On Thu, 2025-01-30 at 17:42 -0500, Vivi, Rodrigo wrote:
> > On Tue, Jan 28, 2025 at 10:36:49AM -0800, Alan Previn wrote:
> > 
> > > 
alan:snip
> > > -       if (!snapshot->matched_node)
> > > +       gt = guc_to_gt(guc);
> > > +       if (!node) {
> > > +               xe_gt_warn(gt, "GuC Capture printing without node!\n");
> > >                 return;
> > > +       }
> > > +       if (!p) {
> > > +               xe_gt_warn(gt, "GuC Capture printing without printer!\n");
> > > +               return;
> > > +       }
> > >  
> > > -       xe_gt_assert(gt, snapshot->hwe);
> > > -
> > > -       capture_class = xe_engine_class_to_guc_capture_class(snapshot->hwe->class);
> > > -
> > > -       drm_printf(p, "%s (physical), logical instance=%d\n",
> > > -                  snapshot->name ? snapshot->name : "",
> > > -                  snapshot->logical_instance);
> > >         drm_printf(p, "\tCapture_source: %s\n",
> > > -                  snapshot->matched_node->source == XE_ENGINE_CAPTURE_SOURCE_GUC ?
> > > +                  node->source == XE_ENGINE_CAPTURE_SOURCE_GUC ?
> > >                    "GuC" : "Manual");
> > 
> > This looks like it is changing the order of the prints. So, please ensure that this
> > is not breaking the decode user space tools.
> alan: good catch Rodrigo, let me double check this against the mesa tool. Although I am wondering
> why the MESA tool would have ever expected non-engine-specific registers (forcewake) to be slotted
> after a couple of GuCFW specific tags (like "Capture source" and "Coverage") followed by
> engine-register dumps. I suspect the location of the GuC-tags could move around.
> Will double check with them.

just a quick update - finally with Jose's + John's help, manage to get the
mesa aubinator tool built and Jose confirmed that the minor change above was
didn't break the decoding. Jose did point out we had an extra newline
so I'll have to fix that. Above hunk doesn't show it, but I think the new
line is on caller of this function. Will fix this along with everything else
and push a new rev shortly.