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

Daniele Ceraolo Spurio daniele.ceraolospurio at intel.com
Mon Jul 6 14:30:57 UTC 2020



On 7/6/2020 7:10 AM, Michał Winiarski wrote:
> 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 at 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 at intel.com>
>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
>>> Cc: Lukasz Fiedorowicz <lukasz.fiedorowicz at intel.com>
>>> Cc: Michal Wajdeczko <michal.wajdeczko at 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?

Ok, I see where you're coming from. For things that touch both GuC and 
HuC we usually go for the uC notation, so IMO a new uc-level file would 
be more appropriate here (e.g. gt/uc/usage).
However, if you have a reason to capture this in a single file with 
other GuC-related details I'm ok if we stick to guc_info.

Daniele

> -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);
>>>    



More information about the Intel-gfx mailing list