Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16 |
|
#
d987150b |
| 22-Dec-2022 |
Wayne Lin <Wayne.Lin@amd.com> |
drm/drm_print: correct format problem
[why & how] __drm_dbg() parameter set format is wrong and not aligned with the format under CONFIG_DRM_USE_DYNAMIC_DEBUG is on. Fix it.
Signed-off-by: Wayne Li
drm/drm_print: correct format problem
[why & how] __drm_dbg() parameter set format is wrong and not aligned with the format under CONFIG_DRM_USE_DYNAMIC_DEBUG is on. Fix it.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
show more ...
|
#
30e94ff7 |
| 17-Jan-2023 |
Nirmoy Das <nirmoy.das@intel.com> |
drm_print: Remove deprecated DRM_DEBUG_KMS_RATELIMITED()
There are no current users of DRM_DEBUG_KMS_RATELIMITED() so remove it.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime
drm_print: Remove deprecated DRM_DEBUG_KMS_RATELIMITED()
There are no current users of DRM_DEBUG_KMS_RATELIMITED() so remove it.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230117180417.21066-2-nirmoy.das@intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
show more ...
|
Revision tags: v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68 |
|
#
16deeb8e |
| 12-Sep-2022 |
Jim Cromie <jim.cromie@gmail.com> |
drm_print: add _ddebug descriptor to drm_*dbg prototypes
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct _ddebug ptr parameter to them, and supply that additional param by replaci
drm_print: add _ddebug descriptor to drm_*dbg prototypes
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct _ddebug ptr parameter to them, and supply that additional param by replacing the '_no_desc' flavor of dyndbg Factory macro currently used with the flavor that supplies the descriptor.
NOTES:
The descriptor gives these fns access to the decorator flags, but they do none of the dynamic-prefixing done by dynamic_emit_prefix(), which is currently static.
DRM already has conventions for logging/messaging; just tossing optional decorations on top probably wouldn't help. Instead, existing flags (or new ones, perhaps 'sd' ala lspci) can be used to make current message conventions optional. This suggests a new drmdbg_prefix_emit() to handle prefixing locally.
For CONFIG_DRM_USE_DYNAMIC_DEBUG=N, just pass null descriptor.
desc->class_id is redundant with category parameter, but its availability is dependent on desc.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-10-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
6ce6fae8 |
| 12-Sep-2022 |
Jim Cromie <jim.cromie@gmail.com> |
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
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>
show more ...
|
#
95a77b63 |
| 12-Sep-2022 |
Jim Cromie <jim.cromie@gmail.com> |
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
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>
show more ...
|
#
ee7d633f |
| 12-Sep-2022 |
Jim Cromie <jim.cromie@gmail.com> |
drm-print.h: include dyndbg header
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2: error: call to undeclared function '_dynamic_func_call_cls'; ISO C99 and later do not support impli
drm-print.h: include dyndbg header
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2: error: call to undeclared function '_dynamic_func_call_cls'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
Since that macro is defined in drm_print.h, and under DRM_USE_DYN*=y configs, invokes dyndbg-factory macros, include dynamic_debug.h from there too, so that those configs have the definitions of all the macros in the callchain.
This is done as a separate patch mostly to see how lkp sorts it.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-6-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
84ec6728 |
| 12-Sep-2022 |
Jim Cromie <jim.cromie@gmail.com> |
drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro
For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg() in one of dyndbg's Factory macros: _dynamic_func_call_no_desc().
drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro
For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg() in one of dyndbg's Factory macros: _dynamic_func_call_no_desc().
This adds the callsite descriptor into the code, and an entry for each into /proc/dynamic_debug/control.
#> echo class DRM_UT_ATOMIC +p > /proc/dynamic_debug/control
CONFIG_DRM_USE_DYNAMIC_DEBUG=y/n is configurable because of the .data footprint cost of per-callsite control; 56 bytes/site * ~2k for i915, ~4k callsites for amdgpu. This is large enough that a kernel builder might not want it.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-5-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e820f525 |
| 12-Sep-2022 |
Jim Cromie <jim.cromie@gmail.com> |
drm_print: interpose drm_*dbg with forwarding macros
change drm_dev_dbg & drm_dbg to macros, which forward to the renamed functions (with __ prefix added).
Those functions sit below the categorized
drm_print: interpose drm_*dbg with forwarding macros
change drm_dev_dbg & drm_dbg to macros, which forward to the renamed functions (with __ prefix added).
Those functions sit below the categorized layer of macros implementing the DRM debug.category API, and implement most of it. These are good places to insert dynamic-debug jump-label mechanics, which will allow DRM to avoid the runtime cost of drm_debug_enabled().
no functional changes.
memory cost baseline: (unchanged) bash-5.1# drms_load [ 9.220389] dyndbg: 1 debug prints in module drm [ 9.224426] ACPI: bus type drm_connector registered [ 9.302192] dyndbg: 2 debug prints in module ttm [ 9.305033] dyndbg: 8 debug prints in module video [ 9.627563] dyndbg: 127 debug prints in module i915 [ 9.721505] AMD-Vi: AMD IOMMUv2 functionality not available on this system - This is not a bug. [ 10.091345] dyndbg: 2196 debug prints in module amdgpu [ 10.106589] [drm] amdgpu kernel modesetting enabled. [ 10.107270] amdgpu: CRAT table not found [ 10.107926] amdgpu: Virtual CRAT table created for CPU [ 10.108398] amdgpu: Topology: Add CPU node [ 10.168507] dyndbg: 3 debug prints in module wmi [ 10.329587] dyndbg: 3 debug prints in module nouveau
Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-4-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
f158936b |
| 12-Sep-2022 |
Jim Cromie <jim.cromie@gmail.com> |
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
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>
show more ...
|
#
0406faf2 |
| 12-Sep-2022 |
Jim Cromie <jim.cromie@gmail.com> |
drm_print: condense enum drm_debug_category
enum drm_debug_category has 10 categories, but is initialized with bitmasks which require 10 bits of underlying storage. By using natural enumeration, an
drm_print: condense enum drm_debug_category
enum drm_debug_category has 10 categories, but is initialized with bitmasks which require 10 bits of underlying storage. By using natural enumeration, and moving the BIT(cat) into drm_debug_enabled(), the enum fits in 4 bits, allowing the category to be represented directly in pr_debug callsites, via the ddebug.class_id field.
While this slightly pessimizes the bit-test in drm_debug_enabled(), using dyndbg with JUMP_LABEL will avoid the function entirely.
NOTE: this change forecloses the possibility of doing:
drm_dbg(DRM_UT_CORE|DRM_UT_KMS, "weird 2-cat experiment")
but thats already strongly implied by the use of the enum itself; its not a normal enum if it can be 2 values simultaneously.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20220912052852.1123868-2-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51 |
|
#
38a523a2 |
| 27-Jun-2022 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm"
This reverts commit 77515ebaf01920e2db49e04672ef669a7c2907f2 as it causes build problems in linux-next. I
Revert "devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm"
This reverts commit 77515ebaf01920e2db49e04672ef669a7c2907f2 as it causes build problems in linux-next. It needs to be reintroduced in a way that can allow the api to evolve and not require a "flag day" to catch all users.
Link: https://lore.kernel.org/r/20220623160723.7a44b573@canb.auug.org.au Cc: Duoming Zhou <duoming@zju.edu.cn> Cc: Brian Norris <briannorris@chromium.org> Cc: Johannes Berg <johannes@sipsolutions.net> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46 |
|
#
77515eba |
| 06-Jun-2022 |
Duoming Zhou <duoming@zju.edu.cn> |
devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm
The dev_coredumpv() and dev_coredumpm() could not be used in atomic context, because they call kvasprintf_const() a
devcoredump: remove the useless gfp_t parameter in dev_coredumpv and dev_coredumpm
The dev_coredumpv() and dev_coredumpm() could not be used in atomic context, because they call kvasprintf_const() and kstrdup() with GFP_KERNEL parameter. The process is shown below:
dev_coredumpv(.., gfp_t gfp) dev_coredumpm(.., gfp_t gfp) dev_set_name kobject_set_name_vargs kvasprintf_const(GFP_KERNEL, ...); //may sleep kstrdup(s, GFP_KERNEL); //may sleep
This patch removes gfp_t parameter of dev_coredumpv() and dev_coredumpm() and changes the gfp_t parameter of kzalloc() in dev_coredumpm() to GFP_KERNEL in order to show they could not be used in atomic context.
Fixes: 833c95456a70 ("device coredump: add new device coredump class") Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/df72af3b1862bac7d8e793d1f3931857d3779dfd.1654569290.git.duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7 |
|
#
30658985 |
| 21-Sep-2021 |
Douglas Anderson <dianders@chromium.org> |
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. A
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
show more ...
|
Revision tags: v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51 |
|
#
51fdf091 |
| 14-Jul-2021 |
Jim Cromie <jim.cromie@gmail.com> |
drm/print: fixup spelling in a comment
s/prink/printk/ - no functional changes
Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://p
drm/print: fixup spelling in a comment
s/prink/printk/ - no functional changes
Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210714175138.319514-2-jim.cromie@gmail.com
show more ...
|
Revision tags: v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12 |
|
#
79119021 |
| 23-Apr-2021 |
Lyude Paul <lyude@redhat.com> |
drm/print: Handle potentially NULL drm_devices in drm_dbg_*
While this shouldn't really be something that happens all that often, since we're going to be using the drm_dbg_* log helpers in DRM helpe
drm/print: Handle potentially NULL drm_devices in drm_dbg_*
While this shouldn't really be something that happens all that often, since we're going to be using the drm_dbg_* log helpers in DRM helpers it's technically possible that a driver could use an AUX adapter before it's been associated with it's respective drm_device. While drivers should take care to avoid this, there's likely going to be situations where it's difficult to workaround. And since other logging helpers in the kernel tend to be OK with NULL pointers (for instance, passing a NULL pointer to a "%s" argument for a printk-like function in the kernel doesn't break anything), we should do the same for ours.
Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-15-lyude@redhat.com Reviewed-by: Dave Airlie <airlied@redhat.com>
show more ...
|
Revision tags: v5.10.32, v5.10.31, v5.10.30, v5.10.27 |
|
#
c5261e93 |
| 26-Mar-2021 |
Lyude Paul <lyude@redhat.com> |
drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()
Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want to make sure that we can also add ratelimited versions of these macros in order
drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()
Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want to make sure that we can also add ratelimited versions of these macros in order to retain some of the previous debugging output behavior we had.
However, as I was preparing to do this I noticed that the current rate limited macros we have are kind of bogus. It looks like when I wrote these, I didn't notice that we'd always be calling __ratelimit() even if the debugging message we'd be printing would normally be filtered out due to the relevant DRM debugging category being disabled.
So, let's fix this by making sure to check drm_debug_enabled() in our ratelimited macros before calling __ratelimit(), and start using drm_dev_printk() in order to print debugging messages since that will save us from doing a redundant drm_debug_enabled() check. And while we're at it, let's move the code for this into another macro that we can reuse for defining new ratelimited DRM debug macros more easily.
v2: * Make sure to use tabs where possible in __DRM_DEFINE_DBG_RATELIMITED()
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Robert Foss <robert.foss@linaro.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-8-lyude@redhat.com
show more ...
|
Revision tags: v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17 |
|
#
b52817e9 |
| 27-Oct-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
drm: drm_print.h: fix kernel-doc markups
A kernel-doc markup should start with the identifier on its first line.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Dani
drm: drm_print.h: fix kernel-doc markups
A kernel-doc markup should start with the identifier on its first line.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/5b76c5625709aaaa3abee98faa620b9f3d27ff85.1603791716.git.mchehab+huawei@kernel.org
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28 |
|
#
c6603c74 |
| 24-Mar-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
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 relea
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
show more ...
|
Revision tags: v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20 |
|
#
acce61bf |
| 14-Feb-2020 |
Sam Ravnborg <sam@ravnborg.org> |
drm/print: clean up RATELIMITED macros
Drop a few indirections, making the code simpler. This also drops a RATELIMITED variant that is not in use.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Rev
drm/print: clean up RATELIMITED macros
Drop a few indirections, making the code simpler. This also drops a RATELIMITED variant that is not in use.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214175919.GA14492@ravnborg.org
show more ...
|
#
7ff6ea0f |
| 14-Feb-2020 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/print: Delete a few unused shouting macros
We want to go over to the new lowercase ones, encourage that a bit more.
v2: Remove the accidentally included hunk from some WIP branch this was based
drm/print: Delete a few unused shouting macros
We want to go over to the new lowercase ones, encourage that a bit more.
v2: Remove the accidentally included hunk from some WIP branch this was based on (Jani&Sam).
Cc: Jani Nikula <jani.nikula@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200214090428.2929833-1-daniel.vetter@ffwll.ch
show more ...
|
Revision tags: v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13 |
|
#
dc1a73e5 |
| 14-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/print: introduce new struct drm_device based WARN* macros
Add new struct drm_device based WARN* macros. These are modeled after the core kernel device based WARN* macros. These would be preferre
drm/print: introduce new struct drm_device based WARN* macros
Add new struct drm_device based WARN* macros. These are modeled after the core kernel device based WARN* macros. These would be preferred over the regular WARN* macros, where possible.
These macros include device information in the backtrace, so we know what device the warnings originate from.
Knowing the device specific information in the backtrace would be helpful in development all around.
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Sean Paul <sean@poorly.run> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-2-pankaj.laxminarayan.bharadiya@intel.com
show more ...
|
Revision tags: v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3 |
|
#
fb6c7ab8 |
| 10-Dec-2019 |
Jani Nikula <jani.nikula@intel.com> |
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 ove
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
show more ...
|
Revision tags: v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8 |
|
#
3bf149bd |
| 28-Oct-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/print: group logging functions by prink or device based
In preparation for adding struct drm_device based logging, group the existing functions by prink or struct device based logging. No functi
drm/print: group logging functions by prink or device based
In preparation for adding struct drm_device based logging, group the existing functions by prink or struct device based logging. No functional changes.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Sean Paul <sean@poorly.run> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/51c70d80e7dd06c49ba3be56fbb6ae70edddc102.1572258936.git.jani.nikula@intel.com
show more ...
|
#
876905b8 |
| 28-Oct-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/print: convert debug category macros into an enum
Mostly for improved documentation, convert the debug category macros into an enum. Drop unused DRM_UT_NONE. Document previously undocumented cat
drm/print: convert debug category macros into an enum
Mostly for improved documentation, convert the debug category macros into an enum. Drop unused DRM_UT_NONE. Document previously undocumented categories.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Sean Paul <sean@poorly.run> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/96582479e7829d92b89adb805f829e23043ca85c.1572258936.git.jani.nikula@intel.com
show more ...
|
#
99acf471 |
| 28-Oct-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/print: underscore prefix functions that should be private to print
We don't want people calling the functions directly. No functional changes.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/print: underscore prefix functions that should be private to print
We don't want people calling the functions directly. No functional changes.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Sean Paul <sean@poorly.run> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6b236ed4d2e6d2987eaaeb9cb737f9c3699281cc.1572258936.git.jani.nikula@intel.com
show more ...
|