2016-11-05 18:08:07 +03:00
/*
* 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_
2017-02-16 02:33:18 +03:00
# include <linux/compiler.h>
# include <linux/printk.h>
2016-11-05 18:08:07 +03:00
# include <linux/seq_file.h>
# include <linux/device.h>
2019-02-21 00:03:37 +03:00
# include <linux/debugfs.h>
2022-09-12 08:28:48 +03:00
# include <linux/dynamic_debug.h>
2016-11-05 18:08:07 +03:00
2019-06-10 01:07:48 +03:00
# include <drm/drm.h>
2019-10-28 13:38:18 +03:00
/* 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 08:28:45 +03:00
extern unsigned long __drm_debug ;
2019-09-24 15:58:57 +03:00
2016-11-05 18:08:07 +03:00
/**
* 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 {
2016-12-28 19:42:09 +03:00
/* private: */
2016-11-05 18:08:07 +03:00
void ( * printfn ) ( struct drm_printer * p , struct va_format * vaf ) ;
2018-07-24 19:33:21 +03:00
void ( * puts ) ( struct drm_printer * p , const char * str ) ;
2016-11-05 18:08:07 +03:00
void * arg ;
2016-12-28 19:42:09 +03:00
const char * prefix ;
2016-11-05 18:08:07 +03:00
} ;
2018-07-24 19:33:20 +03:00
void __drm_printfn_coredump ( struct drm_printer * p , struct va_format * vaf ) ;
2018-07-24 19:33:23 +03:00
void __drm_puts_coredump ( struct drm_printer * p , const char * str ) ;
2016-11-05 18:08:07 +03:00
void __drm_printfn_seq_file ( struct drm_printer * p , struct va_format * vaf ) ;
2018-07-24 19:33:22 +03:00
void __drm_puts_seq_file ( struct drm_printer * p , const char * str ) ;
2016-11-05 18:08:07 +03:00
void __drm_printfn_info ( struct drm_printer * p , struct va_format * vaf ) ;
2016-12-28 19:42:09 +03:00
void __drm_printfn_debug ( struct drm_printer * p , struct va_format * vaf ) ;
2019-09-03 23:45:43 +03:00
void __drm_printfn_err ( struct drm_printer * p , struct va_format * vaf ) ;
2016-11-05 18:08:07 +03:00
2017-02-16 02:33:18 +03:00
__printf ( 2 , 3 )
2016-11-05 18:08:07 +03:00
void drm_printf ( struct drm_printer * p , const char * f , . . . ) ;
2018-07-24 19:33:21 +03:00
void drm_puts ( struct drm_printer * p , const char * str ) ;
2019-02-21 00:03:37 +03:00
void drm_print_regset32 ( struct drm_printer * p , struct debugfs_regset32 * regset ) ;
2019-09-23 09:58:14 +03:00
void drm_print_bits ( struct drm_printer * p , unsigned long value ,
const char * const bits [ ] , unsigned int nbits ) ;
2016-11-05 18:08:07 +03:00
2017-12-14 23:30:51 +03:00
__printf ( 2 , 0 )
2017-11-23 11:40:46 +03:00
/**
* 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 ) ;
}
2017-11-07 22:13:39 +03:00
/**
* 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 \t X " , # # __VA_ARGS__ )
2016-11-05 18:08:07 +03:00
2018-07-24 19:33:20 +03:00
/**
* 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 ,
2018-07-24 19:33:23 +03:00
. puts = __drm_puts_coredump ,
2018-07-24 19:33:20 +03:00
. arg = iter ,
} ;
/* Set the internal offset of the iterator to zero */
iter - > offset = 0 ;
return p ;
}
2016-11-05 18:08:07 +03:00
/**
* drm_seq_file_printer - construct a & drm_printer that outputs to & seq_file
2016-12-29 23:48:26 +03:00
* @ f : the & struct seq_file to output to
2016-11-05 18:08:07 +03:00
*
* 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 ,
2018-07-24 19:33:22 +03:00
. puts = __drm_puts_seq_file ,
2016-11-05 18:08:07 +03:00
. arg = f ,
} ;
return p ;
}
/**
* drm_info_printer - construct a & drm_printer that outputs to dev_printk ( )
2016-12-29 23:48:26 +03:00
* @ dev : the & struct device pointer
2016-11-05 18:08:07 +03:00
*
* 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 ;
}
2016-12-28 19:42:09 +03:00
/**
* 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 ;
}
2017-10-18 07:30:07 +03:00
2019-09-03 23:45:43 +03:00
/**
* 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 ;
}
2019-10-28 13:38:20 +03:00
/**
* enum drm_debug_category - The DRM debug categories
2017-10-18 07:30:07 +03:00
*
2019-10-28 13:38:20 +03:00
* 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 .
2017-10-18 07:30:07 +03:00
*
2019-10-28 13:38:20 +03:00
* Each DRM_DEBUG_ < CATEGORY > macro logs to DRM_UT_ < CATEGORY > category , except
* DRM_DEBUG ( ) logs to DRM_UT_CORE .
2017-10-18 07:30:07 +03:00
*
2019-10-28 13:38:20 +03:00
* Enabling verbose debug messages is done through the drm . debug parameter , each
* category being enabled by a bit :
2017-10-18 07:30:07 +03:00
*
2019-10-28 13:38:20 +03:00
* - 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
2017-10-18 07:30:07 +03:00
*
* An interesting feature is that it ' s possible to enable verbose logging at
2019-10-28 13:38:20 +03:00
* run - time by echoing the debug value in its sysfs node : :
*
2017-10-18 07:30:07 +03:00
* # echo 0xf > / sys / module / drm / parameters / debug
2019-10-28 13:38:20 +03:00
*
2017-10-18 07:30:07 +03:00
*/
2019-10-28 13:38:20 +03:00
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 08:28:45 +03:00
/* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_CORE : Used in the generic drm code : drm_ioctl . c , drm_mm . c ,
* drm_memory . c , . . .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_CORE ,
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_DRIVER : Used in the vendor specific part of the driver : i915 ,
* radeon , . . . macro .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_DRIVER ,
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_KMS : Used in the modesetting code .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_KMS ,
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_PRIME : Used in the prime code .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_PRIME ,
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_ATOMIC : Used in the atomic code .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_ATOMIC ,
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_VBL : Used for verbose debug message in the vblank code .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_VBL ,
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_STATE : Used for verbose atomic state debugging .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_STATE ,
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_LEASE : Used in the lease code .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_LEASE ,
2019-10-28 13:38:20 +03:00
/**
* @ DRM_UT_DP : Used in the DP code .
*/
2022-09-12 08:28:44 +03:00
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 15:45:40 +03:00
/**
* @ DRM_UT_DRMRES : Used in the drm managed resources code .
*/
2022-09-12 08:28:44 +03:00
DRM_UT_DRMRES
2019-10-28 13:38:20 +03:00
} ;
2017-10-18 07:30:07 +03:00
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 08:28:50 +03:00
static inline bool drm_debug_enabled_raw ( enum drm_debug_category category )
2019-10-01 17:06:14 +03:00
{
2022-09-12 08:28:44 +03:00
return unlikely ( __drm_debug & BIT ( category ) ) ;
2019-10-01 17:06:14 +03:00
}
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 08:28:50 +03: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
2019-10-28 13:38:21 +03:00
/*
* 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 15:30:43 +03:00
*
2021-07-14 20:51:34 +03:00
* Prefer drm_device based logging over device or printk based logging .
2019-10-28 13:38:21 +03:00
*/
2018-03-16 23:56:27 +03:00
__printf ( 3 , 4 )
2017-10-18 07:30:07 +03:00
void drm_dev_printk ( const struct device * dev , const char * level ,
2018-03-16 23:56:27 +03:00
const char * format , . . . ) ;
__printf ( 3 , 4 )
2022-09-12 08:28:46 +03:00
void __drm_dev_dbg ( const struct device * dev , enum drm_debug_category category ,
2018-03-16 23:56:27 +03:00
const char * format , . . . ) ;
2017-10-18 07:30:07 +03:00
/**
2020-10-27 12:51:35 +03:00
* DRM_DEV_ERROR ( ) - Error output .
2017-10-18 07:30:07 +03:00
*
2021-09-21 18:28:01 +03:00
* NOTE : this is deprecated in favor of drm_err ( ) or dev_err ( ) .
*
2017-10-18 07:31:22 +03:00
* @ dev : device pointer
* @ fmt : printf ( ) like format string .
2017-10-18 07:30:07 +03:00
*/
# define DRM_DEV_ERROR(dev, fmt, ...) \
2018-03-16 23:56:27 +03:00
drm_dev_printk ( dev , KERN_ERR , " *ERROR* " fmt , # # __VA_ARGS__ )
2017-10-18 07:30:07 +03:00
/**
2020-10-27 12:51:35 +03:00
* DRM_DEV_ERROR_RATELIMITED ( ) - Rate limited error output .
2017-10-18 07:30:07 +03:00
*
2021-09-21 18:28:01 +03:00
* NOTE : this is deprecated in favor of drm_err_ratelimited ( ) or
* dev_err_ratelimited ( ) .
*
2017-10-18 07:31:22 +03:00
* @ dev : device pointer
* @ fmt : printf ( ) like format string .
2020-10-27 12:51:35 +03:00
*
* Like DRM_ERROR ( ) but won ' t flood the log .
2017-10-18 07:30:07 +03:00
*/
# 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__ ) ; \
} )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_info() or dev_info(). */
2019-10-28 13:38:21 +03:00
# define DRM_DEV_INFO(dev, fmt, ...) \
2018-03-16 23:56:27 +03:00
drm_dev_printk ( dev , KERN_INFO , fmt , # # __VA_ARGS__ )
2017-10-18 07:30:07 +03:00
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_info_once() or dev_info_once(). */
2017-10-18 07:30:07 +03:00
# 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__ ) ; \
} \
} )
2022-09-12 08:28:47 +03:00
# if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
2022-09-12 08:28:46 +03:00
# define drm_dev_dbg(dev, cat, fmt, ...) \
__drm_dev_dbg ( dev , cat , fmt , # # __VA_ARGS__ )
2022-09-12 08:28:47 +03:00
# else
# define drm_dev_dbg(dev, cat, fmt, ...) \
_dynamic_func_call_no_desc ( fmt , __drm_dev_dbg , \
dev , cat , fmt , # # __VA_ARGS__ )
# endif
2022-09-12 08:28:46 +03:00
2017-10-18 07:30:07 +03:00
/**
2020-10-27 12:51:35 +03:00
* DRM_DEV_DEBUG ( ) - Debug output for generic drm code
2017-10-18 07:30:07 +03:00
*
2021-09-21 18:28:01 +03:00
* NOTE : this is deprecated in favor of drm_dbg_core ( ) .
*
2017-10-18 07:31:22 +03:00
* @ dev : device pointer
* @ fmt : printf ( ) like format string .
2017-10-18 07:30:07 +03:00
*/
2018-03-16 23:56:27 +03:00
# define DRM_DEV_DEBUG(dev, fmt, ...) \
drm_dev_dbg ( dev , DRM_UT_CORE , fmt , # # __VA_ARGS__ )
2020-10-27 12:51:35 +03:00
/**
* DRM_DEV_DEBUG_DRIVER ( ) - Debug output for vendor specific part of the driver
*
2021-09-21 18:28:01 +03:00
* NOTE : this is deprecated in favor of drm_dbg ( ) or dev_dbg ( ) .
*
2020-10-27 12:51:35 +03:00
* @ dev : device pointer
* @ fmt : printf ( ) like format string .
*/
2018-03-16 23:56:27 +03:00
# define DRM_DEV_DEBUG_DRIVER(dev, fmt, ...) \
drm_dev_dbg ( dev , DRM_UT_DRIVER , fmt , # # __VA_ARGS__ )
2020-10-27 12:51:35 +03:00
/**
* DRM_DEV_DEBUG_KMS ( ) - Debug output for modesetting code
*
2021-09-21 18:28:01 +03:00
* NOTE : this is deprecated in favor of drm_dbg_kms ( ) .
*
2020-10-27 12:51:35 +03:00
* @ dev : device pointer
* @ fmt : printf ( ) like format string .
*/
2018-03-16 23:56:27 +03:00
# define DRM_DEV_DEBUG_KMS(dev, fmt, ...) \
drm_dev_dbg ( dev , DRM_UT_KMS , fmt , # # __VA_ARGS__ )
2018-07-16 18:44:32 +03:00
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 15:30:43 +03: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, ...) \
2021-04-23 21:43:06 +03:00
drm_dev_dbg ( ( drm ) ? ( drm ) - > dev : NULL , DRM_UT_CORE , fmt , # # __VA_ARGS__ )
drm-print: add drm_dbg_driver to improve namespace symmetry
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This will help with nouveau, which uses its own stack of macros to
construct calls to dev_info, dev_dbg, etc, for which adaptation means
drm_dbg_##driver constructs.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Link: https://lore.kernel.org/r/20220912052852.1123868-7-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-12 08:28:49 +03:00
# define drm_dbg_driver(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:30:43 +03:00
# define drm_dbg_kms(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:30:43 +03:00
# define drm_dbg_prime(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:30:43 +03:00
# define drm_dbg_atomic(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:30:43 +03:00
# define drm_dbg_vbl(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:30:43 +03:00
# define drm_dbg_state(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:30:43 +03:00
# define drm_dbg_lease(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:30:43 +03:00
# define drm_dbg_dp(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:45:40 +03:00
# define drm_dbg_drmres(drm, fmt, ...) \
2021-04-23 21:43:06 +03:00
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 15:30:43 +03:00
drm-print: add drm_dbg_driver to improve namespace symmetry
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This will help with nouveau, which uses its own stack of macros to
construct calls to dev_info, dev_dbg, etc, for which adaptation means
drm_dbg_##driver constructs.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Link: https://lore.kernel.org/r/20220912052852.1123868-7-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-09-12 08:28:49 +03: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 15:30:43 +03:00
2019-10-28 13:38:21 +03: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 15:30:43 +03:00
*
* Prefer drm_device based logging over device or prink based logging .
2019-10-28 13:38:21 +03:00
*/
__printf ( 2 , 3 )
2022-09-12 08:28:46 +03:00
void ___drm_dbg ( enum drm_debug_category category , const char * format , . . . ) ;
2019-10-28 13:38:21 +03:00
__printf ( 1 , 2 )
void __drm_err ( const char * format , . . . ) ;
2022-09-12 08:28:47 +03:00
# if !defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
2022-09-12 08:28:46 +03:00
# define __drm_dbg(fmt, ...) ___drm_dbg(fmt, ##__VA_ARGS__)
2022-09-12 08:28:47 +03:00
# else
# define __drm_dbg(cat, fmt, ...) \
_dynamic_func_call_no_desc ( fmt , ___drm_dbg , \
cat , fmt , # # __VA_ARGS__ )
# endif
2022-09-12 08:28:46 +03:00
2019-10-28 13:38:21 +03:00
/* Macros to make printk easier */
# define _DRM_PRINTK(once, level, fmt, ...) \
printk # # once ( KERN_ # # level " [ " DRM_NAME " ] " fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of pr_info(). */
2019-10-28 13:38:21 +03:00
# define DRM_INFO(fmt, ...) \
_DRM_PRINTK ( , INFO , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of pr_notice(). */
2019-10-28 13:38:21 +03:00
# define DRM_NOTE(fmt, ...) \
_DRM_PRINTK ( , NOTICE , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of pr_warn(). */
2019-10-28 13:38:21 +03:00
# define DRM_WARN(fmt, ...) \
_DRM_PRINTK ( , WARNING , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of pr_info_once(). */
2019-10-28 13:38:21 +03:00
# define DRM_INFO_ONCE(fmt, ...) \
_DRM_PRINTK ( _once , INFO , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of pr_notice_once(). */
2019-10-28 13:38:21 +03:00
# define DRM_NOTE_ONCE(fmt, ...) \
_DRM_PRINTK ( _once , NOTICE , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of pr_warn_once(). */
2019-10-28 13:38:21 +03:00
# define DRM_WARN_ONCE(fmt, ...) \
_DRM_PRINTK ( _once , WARNING , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of pr_err(). */
2019-10-28 13:38:21 +03:00
# define DRM_ERROR(fmt, ...) \
__drm_err ( fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of pr_err_ratelimited(). */
2019-10-28 13:38:21 +03:00
# define DRM_ERROR_RATELIMITED(fmt, ...) \
DRM_DEV_ERROR_RATELIMITED ( NULL , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg_core(NULL, ...). */
2019-10-28 13:38:21 +03:00
# define DRM_DEBUG(fmt, ...) \
__drm_dbg ( DRM_UT_CORE , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
2019-10-28 13:38:21 +03:00
# define DRM_DEBUG_DRIVER(fmt, ...) \
__drm_dbg ( DRM_UT_DRIVER , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg_kms(NULL, ...). */
2019-10-28 13:38:21 +03:00
# define DRM_DEBUG_KMS(fmt, ...) \
__drm_dbg ( DRM_UT_KMS , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg_prime(NULL, ...). */
2019-10-28 13:38:21 +03:00
# define DRM_DEBUG_PRIME(fmt, ...) \
__drm_dbg ( DRM_UT_PRIME , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg_atomic(NULL, ...). */
2019-10-28 13:38:21 +03:00
# define DRM_DEBUG_ATOMIC(fmt, ...) \
__drm_dbg ( DRM_UT_ATOMIC , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg_vbl(NULL, ...). */
2019-10-28 13:38:21 +03:00
# define DRM_DEBUG_VBL(fmt, ...) \
__drm_dbg ( DRM_UT_VBL , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg_lease(NULL, ...). */
2019-10-28 13:38:21 +03:00
# define DRM_DEBUG_LEASE(fmt, ...) \
__drm_dbg ( DRM_UT_LEASE , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg_dp(NULL, ...). */
2019-10-28 13:38:21 +03:00
# define DRM_DEBUG_DP(fmt, ...) \
__drm_dbg ( DRM_UT_DP , fmt , # # __VA_ARGS__ )
2021-03-26 23:37:54 +03:00
# 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__ ) ; \
2020-02-14 20:54:42 +03:00
} )
2019-10-28 13:38:21 +03:00
2021-03-26 23:37:54 +03:00
# define drm_dbg_kms_ratelimited(drm, fmt, ...) \
__DRM_DEFINE_DBG_RATELIMITED ( KMS , drm , fmt , # # __VA_ARGS__ )
2021-09-21 18:28:01 +03:00
/* NOTE: this is deprecated in favor of drm_dbg_kms_ratelimited(NULL, ...). */
2021-03-26 23:37:54 +03:00
# define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL, fmt, ## __VA_ARGS__)
2020-01-15 06:44:45 +03:00
/*
* 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 ) " ) " )
2016-11-05 18:08:07 +03:00
# endif /* DRM_PRINT_H_ */