[Intel-xe] [PATCH 1/2] drm/xe: Introduce GT oriented log messages

Michal Wajdeczko michal.wajdeczko at intel.com
Mon Apr 3 08:02:29 UTC 2023



On 24.03.2023 19:36, Rodrigo Vivi wrote:
> On Sun, Mar 12, 2023 at 08:14:41PM +0100, Michal Wajdeczko wrote:
>> While debugging GT related problems, it's good to know which GT was
>> reporting problems. Introduce helper macros to allow prefix GT logs
>> with GT idetifier. We will use them in upcoming patches.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko at intel.com>
>> ---
>>  drivers/gpu/drm/xe/xe_gt_printk.h | 45 +++++++++++++++++++++++++++++++
>>  1 file changed, 45 insertions(+)
>>  create mode 100644 drivers/gpu/drm/xe/xe_gt_printk.h
>>
>> diff --git a/drivers/gpu/drm/xe/xe_gt_printk.h b/drivers/gpu/drm/xe/xe_gt_printk.h
>> new file mode 100644
>> index 000000000000..b12a92024126
>> --- /dev/null
>> +++ b/drivers/gpu/drm/xe/xe_gt_printk.h
>> @@ -0,0 +1,45 @@
>> +/* SPDX-License-Identifier: MIT */
>> +/*
>> + * Copyright © 2023 Intel Corporation
>> + */
>> +
>> +#ifndef _XE_GT_PRINTK_H_
>> +#define _XE_GT_PRINTK_H_
>> +
>> +#include <drm/drm_print.h>
>> +#include "xe_gt_types.h"
>> +
>> +#define gt_printk(_gt, _level, _fmt, ...) \
>> +	drm_##_level(&(_gt)->xe->drm, "GT%u: " _fmt, (_gt)->info.id, ##__VA_ARGS__)
> 
> do we really need this one? setting the level as a second argument sounds not
> aligned with the rest.

this is just internal helper macro for other macros below
same approach as in pci_dev related macros - see [1]

[1] https://elixir.bootlin.com/linux/latest/C/ident/pci_printk

> 
> But everything else in this series is great.

thanks, note updated version here [2]

[2] https://patchwork.freedesktop.org/series/115083/

> you know I hate these macros in general, but this one makes everything
> cleaner and straighforward when you are withing the gt...

IMO we should also have xe_printk and family but there are few who are
strongly against, so I don't even try to send it

> 
> My only concern is that we will always end up with patches using
> the other drm helpers directly... but probably just a matter of time
> until folks gets used to it...

whoever worked with multi-tile issues then he/she will quickly switch to
new macros as this is must-have to be efficient

> 
>> +
>> +#define gt_err(_gt, _fmt, ...) \
>> +	gt_printk((_gt), err, _fmt, ##__VA_ARGS__)
>> +
>> +#define gt_warn(_gt, _fmt, ...) \
>> +	gt_printk((_gt), warn, _fmt, ##__VA_ARGS__)
>> +
>> +#define gt_notice(_gt, _fmt, ...) \
>> +	gt_printk((_gt), notice, _fmt, ##__VA_ARGS__)
>> +
>> +#define gt_info(_gt, _fmt, ...) \
>> +	gt_printk((_gt), info, _fmt, ##__VA_ARGS__)
>> +
>> +#define gt_dbg(_gt, _fmt, ...) \
>> +	gt_printk((_gt), dbg, _fmt, ##__VA_ARGS__)
>> +
>> +#define gt_err_ratelimited(_gt, _fmt, ...) \
>> +	gt_printk((_gt), err_ratelimited, _fmt, ##__VA_ARGS__)
>> +
>> +#define gt_WARN(_gt, _condition, _fmt, ...) \
>> +	drm_WARN(&(_gt)->xe->drm, _condition, "GT%u: " _fmt, (_gt)->info.id, ##__VA_ARGS__)
>> +
>> +#define gt_WARN_ONCE(_gt, _condition, _fmt, ...) \
>> +	drm_WARN_ONCE(&(_gt)->xe->drm, _condition, "GT%u: " _fmt, (_gt)->info.id, ##__VA_ARGS__)
>> +
>> +#define gt_WARN_ON(_gt, _condition) \
>> +	gt_WARN((_gt), _condition, "%s(%s)", "gt_WARN_ON", __stringify(_condition))
>> +
>> +#define gt_WARN_ON_ONCE(_gt, _condition) \
>> +	gt_WARN_ONCE((_gt), _condition, "%s(%s)", "gt_WARN_ON_ONCE", __stringify(_condition))
>> +
>> +#endif
>> -- 
>> 2.25.1
>>


More information about the Intel-xe mailing list