OpenCloudOS-Kernel/include/drm/drm_print.h

641 lines
19 KiB
C
Raw Normal View History

/*
* Copyright (C) 2016 Red Hat
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
* OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*
* Authors:
* Rob Clark <robdclark@gmail.com>
*/
#ifndef DRM_PRINT_H_
#define DRM_PRINT_H_
#include <linux/compiler.h>
#include <linux/printk.h>
#include <linux/seq_file.h>
#include <linux/device.h>
#include <linux/debugfs.h>
#include <linux/dynamic_debug.h>
#include <drm/drm.h>
/* Do *not* use outside of drm_print.[ch]! */
drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers. Use DECLARE_DYNDBG_CLASSMAP across DRM: - in .c files, since macro defines/initializes a record - in drivers, $mod_{drv,drm,param}.c ie where param setup is done, since a classmap is param related - in drm/drm_print.c since existing __drm_debug param is defined there, and we ifdef it, and provide an elaborated alternative. - in drm_*_helper modules: dp/drm_dp - 1st item in makefile target drivers/gpu/drm/drm_crtc_helper.c - random pick iirc. Since these modules all use identical CLASSMAP declarations (ie: names and .class_id's) they will all respond together to "class DRM_UT_*" query-commands: :#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control NOTES: This changes __drm_debug from int to ulong, so BIT() is usable on it. DRM's enum drm_debug_category values need to sync with the index of their respective class-names here. Then .class_id == category, and dyndbg's class FOO mechanisms will enable drm_dbg(DRM_UT_KMS, ...). Though DRM needs consistent categories across all modules, thats not generally needed; modules X and Y could define FOO differently (ie a different NAME => class_id mapping), changes are made according to each module's private class-map. No callsites are actually selected by this patch, since none are class'd yet. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-3-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-12 13:28:45 +08:00
extern unsigned long __drm_debug;
/**
* DOC: print
*
* A simple wrapper for dev_printk(), seq_printf(), etc. Allows same
* debug code to be used for both debugfs and printk logging.
*
* For example::
*
* void log_some_info(struct drm_printer *p)
* {
* drm_printf(p, "foo=%d\n", foo);
* drm_printf(p, "bar=%d\n", bar);
* }
*
* #ifdef CONFIG_DEBUG_FS
* void debugfs_show(struct seq_file *f)
* {
* struct drm_printer p = drm_seq_file_printer(f);
* log_some_info(&p);
* }
* #endif
*
* void some_other_function(...)
* {
* struct drm_printer p = drm_info_printer(drm->dev);
* log_some_info(&p);
* }
*/
/**
* struct drm_printer - drm output "stream"
*
* Do not use struct members directly. Use drm_printer_seq_file(),
* drm_printer_info(), etc to initialize. And drm_printf() for output.
*/
struct drm_printer {
/* private: */
void (*printfn)(struct drm_printer *p, struct va_format *vaf);
void (*puts)(struct drm_printer *p, const char *str);
void *arg;
const char *prefix;
};
void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf);
void __drm_puts_coredump(struct drm_printer *p, const char *str);
void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
void __drm_puts_seq_file(struct drm_printer *p, const char *str);
void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf);
__printf(2, 3)
void drm_printf(struct drm_printer *p, const char *f, ...);
void drm_puts(struct drm_printer *p, const char *str);
void drm_print_regset32(struct drm_printer *p, struct debugfs_regset32 *regset);
void drm_print_bits(struct drm_printer *p, unsigned long value,
const char * const bits[], unsigned int nbits);
__printf(2, 0)
/**
* drm_vprintf - print to a &drm_printer stream
* @p: the &drm_printer
* @fmt: format string
* @va: the va_list
*/
static inline void
drm_vprintf(struct drm_printer *p, const char *fmt, va_list *va)
{
struct va_format vaf = { .fmt = fmt, .va = va };
p->printfn(p, &vaf);
}
/**
* drm_printf_indent - Print to a &drm_printer stream with indentation
* @printer: DRM printer
* @indent: Tab indentation level (max 5)
* @fmt: Format string
*/
#define drm_printf_indent(printer, indent, fmt, ...) \
drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t\t\tX", ##__VA_ARGS__)
/**
* struct drm_print_iterator - local struct used with drm_printer_coredump
* @data: Pointer to the devcoredump output buffer
* @start: The offset within the buffer to start writing
* @remain: The number of bytes to write for this iteration
*/
struct drm_print_iterator {
void *data;
ssize_t start;
ssize_t remain;
/* private: */
ssize_t offset;
};
/**
* drm_coredump_printer - construct a &drm_printer that can output to a buffer
* from the read function for devcoredump
* @iter: A pointer to a struct drm_print_iterator for the read instance
*
* This wrapper extends drm_printf() to work with a dev_coredumpm() callback
* function. The passed in drm_print_iterator struct contains the buffer
* pointer, size and offset as passed in from devcoredump.
*
* For example::
*
* void coredump_read(char *buffer, loff_t offset, size_t count,
* void *data, size_t datalen)
* {
* struct drm_print_iterator iter;
* struct drm_printer p;
*
* iter.data = buffer;
* iter.start = offset;
* iter.remain = count;
*
* p = drm_coredump_printer(&iter);
*
* drm_printf(p, "foo=%d\n", foo);
* }
*
* void makecoredump(...)
* {
* ...
* dev_coredumpm(dev, THIS_MODULE, data, 0, GFP_KERNEL,
* coredump_read, ...)
* }
*
* RETURNS:
* The &drm_printer object
*/
static inline struct drm_printer
drm_coredump_printer(struct drm_print_iterator *iter)
{
struct drm_printer p = {
.printfn = __drm_printfn_coredump,
.puts = __drm_puts_coredump,
.arg = iter,
};
/* Set the internal offset of the iterator to zero */
iter->offset = 0;
return p;
}
/**
* drm_seq_file_printer - construct a &drm_printer that outputs to &seq_file
* @f: the &struct seq_file to output to
*
* RETURNS:
* The &drm_printer object
*/
static inline struct drm_printer drm_seq_file_printer(struct seq_file *f)
{
struct drm_printer p = {
.printfn = __drm_printfn_seq_file,
.puts = __drm_puts_seq_file,
.arg = f,
};
return p;
}
/**
* drm_info_printer - construct a &drm_printer that outputs to dev_printk()
* @dev: the &struct device pointer
*
* RETURNS:
* The &drm_printer object
*/
static inline struct drm_printer drm_info_printer(struct device *dev)
{
struct drm_printer p = {
.printfn = __drm_printfn_info,
.arg = dev,
};
return p;
}
/**
* drm_debug_printer - construct a &drm_printer that outputs to pr_debug()
* @prefix: debug output prefix
*
* RETURNS:
* The &drm_printer object
*/
static inline struct drm_printer drm_debug_printer(const char *prefix)
{
struct drm_printer p = {
.printfn = __drm_printfn_debug,
.prefix = prefix
};
return p;
}
/**
* drm_err_printer - construct a &drm_printer that outputs to pr_err()
* @prefix: debug output prefix
*
* RETURNS:
* The &drm_printer object
*/
static inline struct drm_printer drm_err_printer(const char *prefix)
{
struct drm_printer p = {
.printfn = __drm_printfn_err,
.prefix = prefix
};
return p;
}
/**
* enum drm_debug_category - The DRM debug categories
*
* Each of the DRM debug logging macros use a specific category, and the logging
* is filtered by the drm.debug module parameter. This enum specifies the values
* for the interface.
*
* Each DRM_DEBUG_<CATEGORY> macro logs to DRM_UT_<CATEGORY> category, except
* DRM_DEBUG() logs to DRM_UT_CORE.
*
* Enabling verbose debug messages is done through the drm.debug parameter, each
* category being enabled by a bit:
*
* - drm.debug=0x1 will enable CORE messages
* - drm.debug=0x2 will enable DRIVER messages
* - drm.debug=0x3 will enable CORE and DRIVER messages
* - ...
* - drm.debug=0x1ff will enable all messages
*
* An interesting feature is that it's possible to enable verbose logging at
* run-time by echoing the debug value in its sysfs node::
*
* # echo 0xf > /sys/module/drm/parameters/debug
*
*/
enum drm_debug_category {
drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers. Use DECLARE_DYNDBG_CLASSMAP across DRM: - in .c files, since macro defines/initializes a record - in drivers, $mod_{drv,drm,param}.c ie where param setup is done, since a classmap is param related - in drm/drm_print.c since existing __drm_debug param is defined there, and we ifdef it, and provide an elaborated alternative. - in drm_*_helper modules: dp/drm_dp - 1st item in makefile target drivers/gpu/drm/drm_crtc_helper.c - random pick iirc. Since these modules all use identical CLASSMAP declarations (ie: names and .class_id's) they will all respond together to "class DRM_UT_*" query-commands: :#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control NOTES: This changes __drm_debug from int to ulong, so BIT() is usable on it. DRM's enum drm_debug_category values need to sync with the index of their respective class-names here. Then .class_id == category, and dyndbg's class FOO mechanisms will enable drm_dbg(DRM_UT_KMS, ...). Though DRM needs consistent categories across all modules, thats not generally needed; modules X and Y could define FOO differently (ie a different NAME => class_id mapping), changes are made according to each module's private class-map. No callsites are actually selected by this patch, since none are class'd yet. Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-3-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-12 13:28:45 +08:00
/* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
/**
* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
* drm_memory.c, ...
*/
DRM_UT_CORE,
/**
* @DRM_UT_DRIVER: Used in the vendor specific part of the driver: i915,
* radeon, ... macro.
*/
DRM_UT_DRIVER,
/**
* @DRM_UT_KMS: Used in the modesetting code.
*/
DRM_UT_KMS,
/**
* @DRM_UT_PRIME: Used in the prime code.
*/
DRM_UT_PRIME,
/**
* @DRM_UT_ATOMIC: Used in the atomic code.
*/
DRM_UT_ATOMIC,
/**
* @DRM_UT_VBL: Used for verbose debug message in the vblank code.
*/
DRM_UT_VBL,
/**
* @DRM_UT_STATE: Used for verbose atomic state debugging.
*/
DRM_UT_STATE,
/**
* @DRM_UT_LEASE: Used in the lease code.
*/
DRM_UT_LEASE,
/**
* @DRM_UT_DP: Used in the DP code.
*/
DRM_UT_DP,
drm: add managed resources tied to drm_device We have lots of these. And the cleanup code tends to be of dubious quality. The biggest wrong pattern is that developers use devm_, which ties the release action to the underlying struct device, whereas all the userspace visible stuff attached to a drm_device can long outlive that one (e.g. after a hotunplug while userspace has open files and mmap'ed buffers). Give people what they want, but with more correctness. Mostly copied from devres.c, with types adjusted to fit drm_device and a few simplifications - I didn't (yet) copy over everything. Since the types don't match code sharing looked like a hopeless endeavour. For now it's only super simplified, no groups, you can't remove actions (but kfree exists, we'll need that soon). Plus all specific to drm_device ofc, including the logging. Which I didn't bother to make compile-time optional, since none of the other drm logging is compile time optional either. One tricky bit here is the chicken&egg between allocating your drm_device structure and initiliazing it with drm_dev_init. For perfect onion unwinding we'd need to have the action to kfree the allocation registered before drm_dev_init registers any of its own release handlers. But drm_dev_init doesn't know where exactly the drm_device is emebedded into the overall structure, and by the time it returns it'll all be too late. And forcing drivers to be able clean up everything except the one kzalloc is silly. Work around this by having a very special final_kfree pointer. This also avoids troubles with the list head possibly disappearing from underneath us when we release all resources attached to the drm_device. v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless shuffling while getting everything into shape. v3: Add static to add/del_dr (Neil) Move typo fix to the right patch (Neil) v4: Enforce contract for drmm_add_final_kfree: Use ksize() to check that the drm_device is indeed contained somewhere in the final kfree(). Because we need that or the entire managed release logic blows up in a pile of use-after-frees. Motivated by a discussion with Laurent. v5: Review from Laurent: - %zu instead of casting size_t - header guards - sorting of includes - guarding of data assignment if we didn't allocate it for a NULL pointer - delete spurious newline - cast void* data parameter correctly in ->release call, no idea how this even worked before v6: Review from Sam - Add the kerneldoc for the managed sub-struct back in, even if it doesn't show up in the generated html somehow. - Explain why __always_inline. - Fix bisectability around the final kfree() in drm_dev_relase(). This is just interim code which will disappear again. - Some whitespace polish. - Add debug output when drmm_add_action or drmm_kmalloc fail. v7: My bisectability fix wasn't up to par as noticed by smatch. v8: Remove unecessary {} around if else v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr() helper (Thomas). v10: kfree_const goes boom on the plain "kmalloc" assignment, somehow we need to wrap that in kstrdup_const() too!! Also renumber revision log, I somehow reset it midway thruh. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Neil Armstrong <narmstrong@baylibre.com Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch
2020-03-24 20:45:40 +08:00
/**
* @DRM_UT_DRMRES: Used in the drm managed resources code.
*/
DRM_UT_DRMRES
};
drm_print: optimize drm_debug_enabled for jump-label When CONFIG_DRM_USE_DYNAMIC_DEBUG=y, the drm.debug API (a macro stack, calling _+drm_*dbg() eventually) invokes a dyndbg Factory macro to create a descriptor for each callsite, thus making them individually >control-able. In this case, the calls to _drm_*dbg are unreachable unless the callsite is enabled. So those calls can short-circuit their early do-nothing returns. Provide and use __drm_debug_enabled(), to do this when config'd, or the _raw flags-check otherwize. And since dyndbg is in use, lets also instrument the remaining users of drm_debug_enabled, by wrapping the _raw in a macro with a: pr_debug("todo: is this frequent enough to optimize ?\n"); For CONFIG_DRM_USE_DYNAMIC_DEBUG=n, do no site instrumenting at all, since JUMP_LABEL might be off, and we don't want to make work. With drm, amdgpu, i915, nouveau loaded, heres remaining uses of drm_debug_enabled(), which costs ~1.5kb data to control the pr_debug("todo:..")s. Some of those uses might be ok to use __drm_debug_enabled() by inspection, others might warrant conversion to use dyndbg Factory macros, and that would want callrate data to estimate the savings possible. TBH, any remaining savings are probably small; drm.debug covers the vast bulk of the uses. Maybe "vblank" is the exception. :#> grep todo /proc/dynamic_debug/control | wc 21 168 2357 :#> grep todo /proc/dynamic_debug/control drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:787 [drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:1433 [drm]drm_vblank_enable =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_plane.c:2168 [drm]drm_mode_setplane =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:1359 [drm_display_helper]drm_dp_mst_wait_tx_reply =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:2864 [drm_display_helper]process_single_tx_qlock =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:2909 [drm_display_helper]drm_dp_queue_down_tx =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:1686 [drm_display_helper]drm_dp_mst_update_slots =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_dp.c:1111 [i915]intel_dp_print_rates =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_backlight.c:5434 [i915]cnp_enable_backlight =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_backlight.c:5459 [i915]intel_backlight_device_register =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_opregion.c:43 [i915]intel_opregion_notify_encoder =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_opregion.c:53 [i915]asle_set_backlight =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_bios.c:1088 [i915]intel_bios_is_dsi_present =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_display_debugfs.c:6153 [i915]i915_drrs_ctl_set =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/intel_pcode.c:26 [i915]snb_pcode_read =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/i915_getparam.c:785 [i915]i915_getparam_ioctl =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:282 [amdgpu]vcn_v2_5_process_interrupt =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:433 [amdgpu]vcn_v2_0_process_interrupt =_ "todo: maybe avoid via dyndbg\n" :#> Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-8-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-12 13:28:50 +08:00
static inline bool drm_debug_enabled_raw(enum drm_debug_category category)
{
return unlikely(__drm_debug & BIT(category));
}
drm_print: optimize drm_debug_enabled for jump-label When CONFIG_DRM_USE_DYNAMIC_DEBUG=y, the drm.debug API (a macro stack, calling _+drm_*dbg() eventually) invokes a dyndbg Factory macro to create a descriptor for each callsite, thus making them individually >control-able. In this case, the calls to _drm_*dbg are unreachable unless the callsite is enabled. So those calls can short-circuit their early do-nothing returns. Provide and use __drm_debug_enabled(), to do this when config'd, or the _raw flags-check otherwize. And since dyndbg is in use, lets also instrument the remaining users of drm_debug_enabled, by wrapping the _raw in a macro with a: pr_debug("todo: is this frequent enough to optimize ?\n"); For CONFIG_DRM_USE_DYNAMIC_DEBUG=n, do no site instrumenting at all, since JUMP_LABEL might be off, and we don't want to make work. With drm, amdgpu, i915, nouveau loaded, heres remaining uses of drm_debug_enabled(), which costs ~1.5kb data to control the pr_debug("todo:..")s. Some of those uses might be ok to use __drm_debug_enabled() by inspection, others might warrant conversion to use dyndbg Factory macros, and that would want callrate data to estimate the savings possible. TBH, any remaining savings are probably small; drm.debug covers the vast bulk of the uses. Maybe "vblank" is the exception. :#> grep todo /proc/dynamic_debug/control | wc 21 168 2357 :#> grep todo /proc/dynamic_debug/control drivers/gpu/drm/drm_edid_load.c:178 [drm]edid_load =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:410 [drm]drm_crtc_accurate_vblank_count =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:787 [drm]drm_crtc_vblank_helper_get_vblank_timestamp_internal =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:1491 [drm]drm_vblank_restore =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_vblank.c:1433 [drm]drm_vblank_enable =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/drm_plane.c:2168 [drm]drm_mode_setplane =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:1359 [drm_display_helper]drm_dp_mst_wait_tx_reply =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:2864 [drm_display_helper]process_single_tx_qlock =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:2909 [drm_display_helper]drm_dp_queue_down_tx =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/display/drm_dp_mst_topology.c:1686 [drm_display_helper]drm_dp_mst_update_slots =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_dp.c:1111 [i915]intel_dp_print_rates =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_backlight.c:5434 [i915]cnp_enable_backlight =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_backlight.c:5459 [i915]intel_backlight_device_register =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_opregion.c:43 [i915]intel_opregion_notify_encoder =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_opregion.c:53 [i915]asle_set_backlight =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_bios.c:1088 [i915]intel_bios_is_dsi_present =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/display/intel_display_debugfs.c:6153 [i915]i915_drrs_ctl_set =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/intel_pcode.c:26 [i915]snb_pcode_read =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/i915/i915_getparam.c:785 [i915]i915_getparam_ioctl =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c:282 [amdgpu]vcn_v2_5_process_interrupt =_ "todo: maybe avoid via dyndbg\n" drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:433 [amdgpu]vcn_v2_0_process_interrupt =_ "todo: maybe avoid via dyndbg\n" :#> Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-8-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-12 13:28:50 +08:00
#define drm_debug_enabled_instrumented(category) \
({ \
pr_debug("todo: is this frequent enough to optimize ?\n"); \
drm_debug_enabled_raw(category); \
})
#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
/*
* the drm.debug API uses dyndbg, so each drm_*dbg macro/callsite gets
* a descriptor, and only enabled callsites are reachable. They use
* the private macro to avoid re-testing the enable-bit.
*/
#define __drm_debug_enabled(category) true
#define drm_debug_enabled(category) drm_debug_enabled_instrumented(category)
#else
#define __drm_debug_enabled(category) drm_debug_enabled_raw(category)
#define drm_debug_enabled(category) drm_debug_enabled_raw(category)
#endif
/*
* struct device based logging
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
*
* Prefer drm_device based logging over device or printk based logging.
*/
__printf(3, 4)
void drm_dev_printk(const struct device *dev, const char *level,
const char *format, ...);
struct _ddebug;
__printf(4, 5)
void __drm_dev_dbg(struct _ddebug *desc, const struct device *dev,
enum drm_debug_category category, const char *format, ...);
/**
* DRM_DEV_ERROR() - Error output.
*
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
* NOTE: this is deprecated in favor of drm_err() or dev_err().
*
* @dev: device pointer
* @fmt: printf() like format string.
*/
#define DRM_DEV_ERROR(dev, fmt, ...) \
drm_dev_printk(dev, KERN_ERR, "*ERROR* " fmt, ##__VA_ARGS__)
/**
* DRM_DEV_ERROR_RATELIMITED() - Rate limited error output.
*
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
* NOTE: this is deprecated in favor of drm_err_ratelimited() or
* dev_err_ratelimited().
*
* @dev: device pointer
* @fmt: printf() like format string.
*
* Like DRM_ERROR() but won't flood the log.
*/
#define DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) \
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
DEFAULT_RATELIMIT_INTERVAL, \
DEFAULT_RATELIMIT_BURST); \
\
if (__ratelimit(&_rs)) \
DRM_DEV_ERROR(dev, fmt, ##__VA_ARGS__); \
})
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_info() or dev_info(). */
#define DRM_DEV_INFO(dev, fmt, ...) \
drm_dev_printk(dev, KERN_INFO, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_info_once() or dev_info_once(). */
#define DRM_DEV_INFO_ONCE(dev, fmt, ...) \
({ \
static bool __print_once __read_mostly; \
if (!__print_once) { \
__print_once = true; \
DRM_DEV_INFO(dev, fmt, ##__VA_ARGS__); \
} \
})
#if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
#define drm_dev_dbg(dev, cat, fmt, ...) \
__drm_dev_dbg(NULL, dev, cat, fmt, ##__VA_ARGS__)
#else
#define drm_dev_dbg(dev, cat, fmt, ...) \
_dynamic_func_call_cls(cat, fmt, __drm_dev_dbg, \
dev, cat, fmt, ##__VA_ARGS__)
#endif
/**
* DRM_DEV_DEBUG() - Debug output for generic drm code
*
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
* NOTE: this is deprecated in favor of drm_dbg_core().
*
* @dev: device pointer
* @fmt: printf() like format string.
*/
#define DRM_DEV_DEBUG(dev, fmt, ...) \
drm_dev_dbg(dev, DRM_UT_CORE, fmt, ##__VA_ARGS__)
/**
* DRM_DEV_DEBUG_DRIVER() - Debug output for vendor specific part of the driver
*
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
* NOTE: this is deprecated in favor of drm_dbg() or dev_dbg().
*
* @dev: device pointer
* @fmt: printf() like format string.
*/
#define DRM_DEV_DEBUG_DRIVER(dev, fmt, ...) \
drm_dev_dbg(dev, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
/**
* DRM_DEV_DEBUG_KMS() - Debug output for modesetting code
*
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
* NOTE: this is deprecated in favor of drm_dbg_kms().
*
* @dev: device pointer
* @fmt: printf() like format string.
*/
#define DRM_DEV_DEBUG_KMS(dev, fmt, ...) \
drm_dev_dbg(dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
/*
* struct drm_device based logging
*
* Prefer drm_device based logging over device or prink based logging.
*/
/* Helper for struct drm_device based logging. */
#define __drm_printk(drm, level, type, fmt, ...) \
dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
#define drm_info(drm, fmt, ...) \
__drm_printk((drm), info,, fmt, ##__VA_ARGS__)
#define drm_notice(drm, fmt, ...) \
__drm_printk((drm), notice,, fmt, ##__VA_ARGS__)
#define drm_warn(drm, fmt, ...) \
__drm_printk((drm), warn,, fmt, ##__VA_ARGS__)
#define drm_err(drm, fmt, ...) \
__drm_printk((drm), err,, "*ERROR* " fmt, ##__VA_ARGS__)
#define drm_info_once(drm, fmt, ...) \
__drm_printk((drm), info, _once, fmt, ##__VA_ARGS__)
#define drm_notice_once(drm, fmt, ...) \
__drm_printk((drm), notice, _once, fmt, ##__VA_ARGS__)
#define drm_warn_once(drm, fmt, ...) \
__drm_printk((drm), warn, _once, fmt, ##__VA_ARGS__)
#define drm_err_once(drm, fmt, ...) \
__drm_printk((drm), err, _once, "*ERROR* " fmt, ##__VA_ARGS__)
#define drm_err_ratelimited(drm, fmt, ...) \
__drm_printk((drm), err, _ratelimited, "*ERROR* " fmt, ##__VA_ARGS__)
#define drm_dbg_core(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_CORE, fmt, ##__VA_ARGS__)
#define drm_dbg_driver(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
#define drm_dbg_kms(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_KMS, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
#define drm_dbg_prime(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_PRIME, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
#define drm_dbg_atomic(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
#define drm_dbg_vbl(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_VBL, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
#define drm_dbg_state(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_STATE, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
#define drm_dbg_lease(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
#define drm_dbg_dp(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, ##__VA_ARGS__)
drm: add managed resources tied to drm_device We have lots of these. And the cleanup code tends to be of dubious quality. The biggest wrong pattern is that developers use devm_, which ties the release action to the underlying struct device, whereas all the userspace visible stuff attached to a drm_device can long outlive that one (e.g. after a hotunplug while userspace has open files and mmap'ed buffers). Give people what they want, but with more correctness. Mostly copied from devres.c, with types adjusted to fit drm_device and a few simplifications - I didn't (yet) copy over everything. Since the types don't match code sharing looked like a hopeless endeavour. For now it's only super simplified, no groups, you can't remove actions (but kfree exists, we'll need that soon). Plus all specific to drm_device ofc, including the logging. Which I didn't bother to make compile-time optional, since none of the other drm logging is compile time optional either. One tricky bit here is the chicken&egg between allocating your drm_device structure and initiliazing it with drm_dev_init. For perfect onion unwinding we'd need to have the action to kfree the allocation registered before drm_dev_init registers any of its own release handlers. But drm_dev_init doesn't know where exactly the drm_device is emebedded into the overall structure, and by the time it returns it'll all be too late. And forcing drivers to be able clean up everything except the one kzalloc is silly. Work around this by having a very special final_kfree pointer. This also avoids troubles with the list head possibly disappearing from underneath us when we release all resources attached to the drm_device. v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless shuffling while getting everything into shape. v3: Add static to add/del_dr (Neil) Move typo fix to the right patch (Neil) v4: Enforce contract for drmm_add_final_kfree: Use ksize() to check that the drm_device is indeed contained somewhere in the final kfree(). Because we need that or the entire managed release logic blows up in a pile of use-after-frees. Motivated by a discussion with Laurent. v5: Review from Laurent: - %zu instead of casting size_t - header guards - sorting of includes - guarding of data assignment if we didn't allocate it for a NULL pointer - delete spurious newline - cast void* data parameter correctly in ->release call, no idea how this even worked before v6: Review from Sam - Add the kerneldoc for the managed sub-struct back in, even if it doesn't show up in the generated html somehow. - Explain why __always_inline. - Fix bisectability around the final kfree() in drm_dev_relase(). This is just interim code which will disappear again. - Some whitespace polish. - Add debug output when drmm_add_action or drmm_kmalloc fail. v7: My bisectability fix wasn't up to par as noticed by smatch. v8: Remove unecessary {} around if else v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr() helper (Thomas). v10: kfree_const goes boom on the plain "kmalloc" assignment, somehow we need to wrap that in kstrdup_const() too!! Also renumber revision log, I somehow reset it midway thruh. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Neil Armstrong <narmstrong@baylibre.com Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch
2020-03-24 20:45:40 +08:00
#define drm_dbg_drmres(drm, fmt, ...) \
drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRMRES, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
#define drm_dbg(drm, fmt, ...) drm_dbg_driver(drm, fmt, ##__VA_ARGS__)
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
/*
* printk based logging
drm/print: introduce new struct drm_device based logging macros Add new struct drm_device based logging macros modeled after the core kernel device based logging macros. These would be preferred over the drm printk and struct device based macros in drm code, where possible. We have existing drm specific struct device based logging functions, but they are too verbose to use for two main reasons: * The names are unnecessarily long, for example DRM_DEV_DEBUG_KMS(). * The use of struct device over struct drm_device is too generic for most users, leading to an extra dereference. For example: DRM_DEV_DEBUG_KMS(drm->dev, "Hello, world\n"); vs. drm_dbg_kms(drm, "Hello, world\n"); It's a matter of taste, but the SHOUTING UPPERCASE has been argued to be less readable than lowercase. Some names are changed from old DRM names to be based on the core kernel logging functions. For example, NOTE -> notice, ERROR -> err, DEBUG -> dbg. Due to the conflation of DRM_DEBUG and DRM_DEBUG_DRIVER macro use (DRM_DEBUG is used widely in drivers though it's supposed to be a core debugging category), they are named as drm_dbg_core and drm_dbg, respectively. The drm_err and _once/_ratelimited variants no longer include the function name in order to be able to use the core device based logging macros. Arguably this is not a significant change; error messages should not be so common to be only distinguishable by the function name. Ratelimited debug logging macros are to be added later. Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Sean Paul <sean@poorly.run> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191210123050.8799-1-jani.nikula@intel.com
2019-12-10 20:30:43 +08:00
*
* Prefer drm_device based logging over device or prink based logging.
*/
__printf(3, 4)
void ___drm_dbg(struct _ddebug *desc, enum drm_debug_category category, const char *format, ...);
__printf(1, 2)
void __drm_err(const char *format, ...);
#if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
#define __drm_dbg(fmt, ...) ___drm_dbg(NULL, fmt, ##__VA_ARGS__)
#else
#define __drm_dbg(cat, fmt, ...) \
_dynamic_func_call_cls(cat, fmt, ___drm_dbg, \
cat, fmt, ##__VA_ARGS__)
#endif
/* Macros to make printk easier */
#define _DRM_PRINTK(once, level, fmt, ...) \
printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of pr_info(). */
#define DRM_INFO(fmt, ...) \
_DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of pr_notice(). */
#define DRM_NOTE(fmt, ...) \
_DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of pr_warn(). */
#define DRM_WARN(fmt, ...) \
_DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of pr_info_once(). */
#define DRM_INFO_ONCE(fmt, ...) \
_DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of pr_notice_once(). */
#define DRM_NOTE_ONCE(fmt, ...) \
_DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of pr_warn_once(). */
#define DRM_WARN_ONCE(fmt, ...) \
_DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of pr_err(). */
#define DRM_ERROR(fmt, ...) \
__drm_err(fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of pr_err_ratelimited(). */
#define DRM_ERROR_RATELIMITED(fmt, ...) \
DRM_DEV_ERROR_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg_core(NULL, ...). */
#define DRM_DEBUG(fmt, ...) \
__drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
#define DRM_DEBUG_DRIVER(fmt, ...) \
__drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg_kms(NULL, ...). */
#define DRM_DEBUG_KMS(fmt, ...) \
__drm_dbg(DRM_UT_KMS, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg_prime(NULL, ...). */
#define DRM_DEBUG_PRIME(fmt, ...) \
__drm_dbg(DRM_UT_PRIME, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg_atomic(NULL, ...). */
#define DRM_DEBUG_ATOMIC(fmt, ...) \
__drm_dbg(DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg_vbl(NULL, ...). */
#define DRM_DEBUG_VBL(fmt, ...) \
__drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg_lease(NULL, ...). */
#define DRM_DEBUG_LEASE(fmt, ...) \
__drm_dbg(DRM_UT_LEASE, fmt, ##__VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg_dp(NULL, ...). */
#define DRM_DEBUG_DP(fmt, ...) \
__drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...) \
({ \
static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL, DEFAULT_RATELIMIT_BURST);\
const struct drm_device *drm_ = (drm); \
\
if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(&rs_)) \
drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## __VA_ARGS__); \
})
#define drm_dbg_kms_ratelimited(drm, fmt, ...) \
__DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
drm/print: Add deprecation notes to DRM_...() functions It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
2021-09-21 23:28:01 +08:00
/* NOTE: this is deprecated in favor of drm_dbg_kms_ratelimited(NULL, ...). */
#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL, fmt, ## __VA_ARGS__)
/*
* struct drm_device based WARNs
*
* drm_WARN*() acts like WARN*(), but with the key difference of
* using device specific information so that we know from which device
* warning is originating from.
*
* Prefer drm_device based drm_WARN* over regular WARN*
*/
/* Helper for struct drm_device based WARNs */
#define drm_WARN(drm, condition, format, arg...) \
WARN(condition, "%s %s: " format, \
dev_driver_string((drm)->dev), \
dev_name((drm)->dev), ## arg)
#define drm_WARN_ONCE(drm, condition, format, arg...) \
WARN_ONCE(condition, "%s %s: " format, \
dev_driver_string((drm)->dev), \
dev_name((drm)->dev), ## arg)
#define drm_WARN_ON(drm, x) \
drm_WARN((drm), (x), "%s", \
"drm_WARN_ON(" __stringify(x) ")")
#define drm_WARN_ON_ONCE(drm, x) \
drm_WARN_ONCE((drm), (x), "%s", \
"drm_WARN_ON_ONCE(" __stringify(x) ")")
#endif /* DRM_PRINT_H_ */