<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/drm/drm_print.h, branch v6.1.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-10-17T13:21:46+00:00</updated>
<entry>
<title>drm/printer: Allow NULL data in devcoredump printer</title>
<updated>2024-10-17T13:21:46+00:00</updated>
<author>
<name>Matthew Brost</name>
<email>matthew.brost@intel.com</email>
</author>
<published>2024-08-01T15:41:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c0c58a52d782b41be48985a983c2feb39b130eb7'/>
<id>urn:sha1:c0c58a52d782b41be48985a983c2feb39b130eb7</id>
<content type='text'>
[ Upstream commit 53369581dc0c68a5700ed51e1660f44c4b2bb524 ]

We want to determine the size of the devcoredump before writing it out.
To that end, we will run the devcoredump printer with NULL data to get
the size, alloc data based on the generated offset, then run the
devcorecump again with a valid data pointer to print.  This necessitates
not writing data to the data pointer on the initial pass, when it is
NULL.

v5:
 - Better commit message (Jonathan)
 - Add kerenl doc with examples (Jani)

Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Acked-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Signed-off-by: Matthew Brost &lt;matthew.brost@intel.com&gt;
Reviewed-by: Jonathan Cavitt &lt;jonathan.cavitt@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20240801154118.2547543-3-matthew.brost@intel.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/drm_print: correct format problem</title>
<updated>2023-03-10T08:33:57+00:00</updated>
<author>
<name>Wayne Lin</name>
<email>Wayne.Lin@amd.com</email>
</author>
<published>2022-12-23T01:57:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=214cdbe17923f5e1ed1ff7ba19bac0901fc887e4'/>
<id>urn:sha1:214cdbe17923f5e1ed1ff7ba19bac0901fc887e4</id>
<content type='text'>
[ Upstream commit d987150b539271b0394f24c1c648d2846662adb4 ]

[why &amp; 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 &lt;Wayne.Lin@amd.com&gt;
Signed-off-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Acked-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Reviewed-by: Lyude Paul &lt;lyude@redhat.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm_print: add _ddebug descriptor to drm_*dbg prototypes</title>
<updated>2022-09-24T13:02:02+00:00</updated>
<author>
<name>Jim Cromie</name>
<email>jim.cromie@gmail.com</email>
</author>
<published>2022-09-12T05:28:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=16deeb8e18cafd30e70d8dc2b12a753b28298d8a'/>
<id>urn:sha1:16deeb8e18cafd30e70d8dc2b12a753b28298d8a</id>
<content type='text'>
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-&gt;class_id is redundant with category parameter, but its
availability is dependent on desc.

Signed-off-by: Jim Cromie &lt;jim.cromie@gmail.com&gt;
Link: https://lore.kernel.org/r/20220912052852.1123868-10-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm_print: optimize drm_debug_enabled for jump-label</title>
<updated>2022-09-24T13:02:02+00:00</updated>
<author>
<name>Jim Cromie</name>
<email>jim.cromie@gmail.com</email>
</author>
<published>2022-09-12T05:28:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6ce6fae8453687e39e564dc15b6142fe79d76ad5'/>
<id>urn:sha1:6ce6fae8453687e39e564dc15b6142fe79d76ad5</id>
<content type='text'>
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
&gt;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.

:#&gt; grep todo /proc/dynamic_debug/control | wc
     21     168    2357
:#&gt; 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"
:#&gt;

Signed-off-by: Jim Cromie &lt;jim.cromie@gmail.com&gt;
Link: https://lore.kernel.org/r/20220912052852.1123868-8-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm-print: add drm_dbg_driver to improve namespace symmetry</title>
<updated>2022-09-24T13:02:02+00:00</updated>
<author>
<name>Jim Cromie</name>
<email>jim.cromie@gmail.com</email>
</author>
<published>2022-09-12T05:28:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=95a77b6331c2d2313aa843fa77ec91cd092ab0e4'/>
<id>urn:sha1:95a77b6331c2d2313aa843fa77ec91cd092ab0e4</id>
<content type='text'>
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 &lt;jim.cromie@gmail.com&gt;
Link: https://lore.kernel.org/r/20220912052852.1123868-7-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm-print.h: include dyndbg header</title>
<updated>2022-09-24T13:02:02+00:00</updated>
<author>
<name>Jim Cromie</name>
<email>jim.cromie@gmail.com</email>
</author>
<published>2022-09-12T05:28:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ee7d633f2dfb12bac90898edf2ceb5f43a4957eb'/>
<id>urn:sha1:ee7d633f2dfb12bac90898edf2ceb5f43a4957eb</id>
<content type='text'>
lkp robot told me:

  &gt;&gt; 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 &lt;jim.cromie@gmail.com&gt;
Link: https://lore.kernel.org/r/20220912052852.1123868-6-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro</title>
<updated>2022-09-24T13:02:01+00:00</updated>
<author>
<name>Jim Cromie</name>
<email>jim.cromie@gmail.com</email>
</author>
<published>2022-09-12T05:28:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=84ec67288c10fbf136aa050d00b0fe7a89655da0'/>
<id>urn:sha1:84ec67288c10fbf136aa050d00b0fe7a89655da0</id>
<content type='text'>
For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() &amp; __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.

  #&gt; echo class DRM_UT_ATOMIC +p &gt; /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 &lt;jim.cromie@gmail.com&gt;
Link: https://lore.kernel.org/r/20220912052852.1123868-5-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm_print: interpose drm_*dbg with forwarding macros</title>
<updated>2022-09-24T13:02:01+00:00</updated>
<author>
<name>Jim Cromie</name>
<email>jim.cromie@gmail.com</email>
</author>
<published>2022-09-12T05:28:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e820f52577b14c63f7a15f534e17088d3c6afa6c'/>
<id>urn:sha1:e820f52577b14c63f7a15f534e17088d3c6afa6c</id>
<content type='text'>
change drm_dev_dbg &amp; 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 &lt;jim.cromie@gmail.com&gt;
Link: https://lore.kernel.org/r/20220912052852.1123868-4-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers.</title>
<updated>2022-09-24T13:02:01+00:00</updated>
<author>
<name>Jim Cromie</name>
<email>jim.cromie@gmail.com</email>
</author>
<published>2022-09-12T05:28:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f158936b60a7874f29cf8de8d83191ad69119c11'/>
<id>urn:sha1:f158936b60a7874f29cf8de8d83191ad69119c11</id>
<content type='text'>
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:

  :#&gt; echo class DRM_UT_KMS +p &gt; /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 =&gt; 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 &lt;jim.cromie@gmail.com&gt;
Link: https://lore.kernel.org/r/20220912052852.1123868-3-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm_print: condense enum drm_debug_category</title>
<updated>2022-09-24T13:02:01+00:00</updated>
<author>
<name>Jim Cromie</name>
<email>jim.cromie@gmail.com</email>
</author>
<published>2022-09-12T05:28:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0406faf25fb12d29cb1823e641c6f3f3e2037735'/>
<id>urn:sha1:0406faf25fb12d29cb1823e641c6f3f3e2037735</id>
<content type='text'>
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 &lt;jim.cromie@gmail.com&gt;
Link: https://lore.kernel.org/r/20220912052852.1123868-2-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
