Re: [Intel-gfx] [PATCH] drm/i915/guc: Expand guc_info debugfs with more information

["Michał Winiarski" <michal@hardline.pl>]

Quoting Daniele Ceraolo Spurio (2020-07-01 18:45:52)
> 
> 
> On 7/1/2020 7:27 AM, Michał Winiarski wrote:
> > From: Michał Winiarski <michal.winiarski@intel.com>
> >
> > The information about platform/driver/user view of GuC firmware usage
> > currently requires user to either go through kernel log or parse the
> > combination of "enable_guc" modparam and various debugfs entries.
> > Let's keep things simple and add a "supported/used/wanted" matrix
> > (already used internally by i915) in guc_info debugfs.
> >
> > Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> > Cc: Lukasz Fiedorowicz <lukasz.fiedorowicz@intel.com>
> > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > ---
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c | 23 ++++++++++++++++-------
> >   1 file changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > index 861657897c0f..446a41946f56 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > @@ -733,19 +733,28 @@ int intel_guc_allocate_and_map_vma(struct intel_guc *guc, u32 size,
> >    */
> >   void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p)
> >   {
> > +     struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
> >       struct intel_gt *gt = guc_to_gt(guc);
> >       struct intel_uncore *uncore = gt->uncore;
> >       intel_wakeref_t wakeref;
> >   
> > -     if (!intel_guc_is_supported(guc)) {
> > -             drm_printf(p, "GuC not supported\n");
> > +     drm_printf(p, "[guc] supported:%s wanted:%s used:%s\n",
> > +                yesno(intel_uc_supports_guc(uc)),
> > +                yesno(intel_uc_wants_guc(uc)),
> > +                yesno(intel_uc_uses_guc(uc)));
> 
> There are intel_guc equivalents for there uc functions, so we can use 
> those and avoid the intel_uc var if we ditch the HuC (see comment below):
> 
> intel_guc_is_supported
> intel_guc_is_wanted
> intel_guc_is_used
> 
> Same for the others.
> 
> > +     drm_printf(p, "[huc] supported:%s wanted:%s used:%s\n",
> > +                yesno(intel_uc_supports_huc(uc)),
> > +                yesno(intel_uc_wants_huc(uc)),
> > +                yesno(intel_uc_uses_huc(uc)));
> 
> The HuC view should go to the huc_info debugfs

This was intentional. For HuC the "wants" part is controlled by "enable_guc",
and it's actually helpful to see that "guc is used because the user/platform
wants huc", all in the single "cat guc_info".
In other words - this is still (at least partially) GuC view :)

So, given the above, do you still think we should move it to huc_info?

-Michał

> 
> > +     drm_printf(p, "[submission] supported:%s wanted:%s used:%s\n",
> > +                yesno(intel_uc_supports_guc_submission(uc)),
> > +                yesno(intel_uc_wants_guc_submission(uc)),
> > +                yesno(intel_uc_uses_guc_submission(uc)));
> > +
> > +     if (!intel_guc_is_supported(guc) || !intel_guc_is_wanted(guc))
> 
> intel_guc_is_wanted implies intel_guc_is_supported so you can 
> potentially test only that, but I agree that having both is clearer to read.
> 
> Daniele
> 
> >               return;
> > -     }
> >   
> > -     if (!intel_guc_is_wanted(guc)) {
> > -             drm_printf(p, "GuC disabled\n");
> > -             return;
> > -     }
> > +     drm_puts(p, "\n");
> >   
> >       intel_uc_fw_dump(&guc->fw, p);
> >   
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx