Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: Add GuC CT specific debug print wrappers

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 06/01/2023 18:57, John Harrison wrote:
> On 12/6/2022 03:06, Tvrtko Ursulin wrote:
>> On 05/12/2022 18:44, Michal Wajdeczko wrote:
>>> On 05.12.2022 14:16, Tvrtko Ursulin wrote:
>>>> On 02/12/2022 20:14, John Harrison wrote:
>>>> [snip]
>>>>
>>>>> Random meaningless (to me) message that is apparently a display thing:
>>>>> drm_dbg_kms(&dev_priv->drm, "disabling %s\n", pll->info->name);
>>>>> i915 0000:00:02.0: [drm:intel_disable_shared_dpll [i915]] disabling
>>>>> PORT PLL B
>>>>
>>>> Plan is to not touch outside gt/.
> For some unexplicable reason that means it is almost impossible to see 
> the actual problems in most CI dmesg logs because they are swamped with 
> irrelevant display messages that cannot be filtered out. For example, I 
> recently manually grep'd out all the display spam from a bug report log. 
> The dmesg file went from 12MB to 700KB. That is a significant problem 
> that makes bug triage way harder than it needs to be.

I didn't get this part, how it would reduce the amount of spam by adding 
new macros? Anyway, that's something to split out and discuss with 
display folks.

>> Maybe as a way forward work could be split? If John wants to deal with 
>> gt_xxx macros, avoid touching GuC (putting his original motivation 
>> aside) and you want to convert the gt/uc folder? Assuming John you are 
>> okay with "GuC:" and "CT:" prefixes.
> Meaning just repost patch #1 only and expand to more intel_gt_* files? 
> Sure, if someone will actually reply to that patch with some kind of r-b 
> first so I know I'm not still wasting my time on a huge re-write that 
> will to be redone multiple times when someone objects to the use of a 
> colon or the lack of spaces, braces or whatever.

First patch looks good to me (ack in principle) apart that Michal found 
one potential null pointer dereference if I understood it right. That 
other comment about the ratelimited call is maybe okay to leave for 
later, *if* it will be a single instance, otherwise needs a gt logger as 
well. I can r-b once you re-send with the first issue fixed.

Regards,

Tvrtko