[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