<div dir="ltr"><div dir="ltr"><br><br>On Mon, Sep 6, 2021 at 6:26 AM Tvrtko Ursulin <<a href="mailto:tvrtko.ursulin@linux.intel.com">tvrtko.ursulin@linux.intel.com</a>> wrote:<br>><br>><br>> On 03/09/2021 20:22, <a href="mailto:jim.cromie@gmail.com">jim.cromie@gmail.com</a> wrote:<br>> > On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin<br>> > <<a href="mailto:tvrtko.ursulin@linux.intel.com">tvrtko.ursulin@linux.intel.com</a>> wrote:<br>> >><br>> >><br>> >> On 31/08/2021 21:21, Jim Cromie wrote:<br>> >>> The gvt component of this driver has ~120 pr_debugs, in 9 categories<br>> >>> quite similar to those in DRM. Following the interface model of<br>> >>> drm.debug, add a parameter to map bits to these categorizations.<br>> >>><br>> >>> DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,<br>> >>> "dyndbg bitmap desc",<br>> >>> { "gvt:cmd: ", "command processing" },<br><br>> >>> v7:<br>> >>> . move ccflags addition up to i915/Makefile from i915/gvt<br>> >>> ---<br>> >>> drivers/gpu/drm/i915/Makefile | 4 ++++<br>> >>> drivers/gpu/drm/i915/i915_params.c | 35 ++++++++++++++++++++++++++++++<br>> >><br>> >> Can this work if put under gvt/ or at least intel_gvt.h|c?<br><br>I tried this.<br>I moved the code block into gvt/debug.c (new file)<br>added it to Makefile GVT_SOURCES<br>dunno why it wont make.<br>frustratig basic err, Im not seeing.<br>It does seem proper placement, will resolve...<br><br><br>> >><br>> ><br>> > I thought it belonged here more, at least according to the name of the<br>> > config.var<br>><br>> Hmm bear with me please - the categories this patch creates are intended<br>> to be used explicitly from the GVT "sub-module", or they somehow even<br>> get automatically used with no further intervention to callers required?<br>><br><br>2009 - v5.9.0 the only users were admins reading/echoing /proc/dynamic_debug/control<br>presumably cuz they wanted more info in the logs, episodically.<br>v5.9.0 exported dynamic_debug_exec_queries for in-kernel use,<br>reusing the stringy: echo $query_command > control idiom.<br>My intention was to let in-kernel users roll their own drm.debug type interface,<br>or whatever else they needed. nobodys using it yet.<br><br>patch 1/8 implements that drm.debug interface.<br>5/8 is the primary use case<br>3/8 (this patch) & 4/8 are patches of opportunity, test cases, proof of function/utility.<br>its value as such is easier control of those pr-debugs than given by echo > control<br><br>Sean Paul <a href="mailto:seanpaul@chromium.org">seanpaul@chromium.org</a> worked up a patchset to do runtime steering of drm-debug stream,</div><div>in particular watching for drm:atomic:fail: type activity (a subcategory which doesnt exist yet).</div><div>5/8 conflicts with his patchset, I have an rfc approach to that, so his concerns are mine too.</div><div dir="ltr"><br></div><div dir="ltr"><br>note: if this patchset goes in, we dont *really* need the export anymore,<br>since the main use case is covered. We could un-export, and re-add later<br>if its needed for a different use case. Further, it seems likely that the callbacks<br>(refactored) would be a better basis for new in-kernel users.<br>If not that, then full exposure of struct ddebug_query to in-kernel use<br><br></div><div><br></div>not quite sure how we got 2 chunks, but theres 1 more q below.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 6, 2021 at 6:26 AM Tvrtko Ursulin <<a href="mailto:tvrtko.ursulin@linux.intel.com">tvrtko.ursulin@linux.intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 03/09/2021 20:22, <a href="mailto:jim.cromie@gmail.com" target="_blank">jim.cromie@gmail.com</a> wrote:<br>
> On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin<br>
> <<a href="mailto:tvrtko.ursulin@linux.intel.com" target="_blank">tvrtko.ursulin@linux.intel.com</a>> wrote:<br>
>><br>
>><br>
>> On 31/08/2021 21:21, Jim Cromie wrote:<br>
>>> The gvt component of this driver has ~120 pr_debugs, in 9 categories<br>
>>> quite similar to those in DRM. Following the interface model of<br>
>>> drm.debug, add a parameter to map bits to these categorizations.<br>
>>><br>
>>> DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,<br>
>>> "dyndbg bitmap desc",<br>
>>> { "gvt:cmd: ", "command processing" },<br>
>>> { "gvt:core: ", "core help" },<br>
>>> { "gvt:dpy: ", "display help" },<br>
>>> { "gvt:el: ", "help" },<br>
>>> { "gvt:irq: ", "help" },<br>
>>> { "gvt:mm: ", "help" },<br>
>>> { "gvt:mmio: ", "help" },<br>
>>> { "gvt:render: ", "help" },<br>
>>> { "gvt:sched: " "help" });<br>
>>><br>
> <br>
> BTW, Ive dropped the help field, its already handled, dont need to clutter.<br>
> <br>
> <br>
>>> The actual patch has a few details different, cmd_help() macro emits<br>
>>> the initialization construct.<br>
>>><br>
>>> if CONFIG_DRM_USE_DYNAMIC_DEBUG, then -DDYNAMIC_DEBUG_MODULE is added<br>
>>> cflags, by gvt/Makefile.<br>
>>><br>
>>> Signed-off-by: Jim Cromie <<a href="mailto:jim.cromie@gmail.com" target="_blank">jim.cromie@gmail.com</a>><br>
>>> ---<br>
>>> v5:<br>
>>> . static decl of vector of bit->class descriptors - Emil.V<br>
>>> . relocate gvt-makefile chunk from elsewhere<br>
>>> v7:<br>
>>> . move ccflags addition up to i915/Makefile from i915/gvt<br>
>>> ---<br>
>>> drivers/gpu/drm/i915/Makefile | 4 ++++<br>
>>> drivers/gpu/drm/i915/i915_params.c | 35 ++++++++++++++++++++++++++++++<br>
>><br>
>> Can this work if put under gvt/ or at least intel_gvt.h|c?<br>
>><br>
> <br>
> I thought it belonged here more, at least according to the name of the<br>
> config.var<br>
<br>
Hmm bear with me please - the categories this patch creates are intended <br>
to be used explicitly from the GVT "sub-module", or they somehow even <br>
get automatically used with no further intervention to callers required?<br>
<br>
> CONFIG_DRM_USE_DYNAMIC_DEBUG.<br>
> <br>
> I suppose its not a great name, its narrow purpose is to swap<br>
> drm-debug api to use dyndbg. drm-evrything already "uses"<br>
> dyndbg if CONFIG_DYNAMIC_DEBUG=y, those gvt/pr_debugs in particular.<br>
> <br>
> Theres also CONFIG_DYNAMIC_DEBUG_CORE=y,<br>
> which drm basically ignores currently.<br>
> <br>
> So with the name CONFIG_DRM_USE_DYNAMIC_DEBUG<br>
> it seemed proper to arrange for that to be true on DD-CORE=y builds,<br>
> by adding -DDYNAMIC_DEBUG_MODULE<br>
> <br>
> Does that make some sense ?<br>
> How to best resolve the frictions ?<br>
> new CONFIG names ?<br>
> <br>
>>> 2 files changed, 39 insertions(+)<br>
>>><br>
>>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile<br>
>>> index 4f22cac1c49b..5a4e371a3ec2 100644<br>
>>> --- a/drivers/gpu/drm/i915/Makefile<br>
>>> +++ b/drivers/gpu/drm/i915/Makefile<br>
>>> @@ -30,6 +30,10 @@ CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)<br>
>>><br>
>>> subdir-ccflags-y += -I$(srctree)/$(src)<br>
>>><br>
>>> +#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG<br>
>>> +ccflags-y += -DDYNAMIC_DEBUG_MODULE<br>
>>> +#endif<br>
>><br>
>> Ignores whether CONFIG_DRM_I915_GVT is enabled or not?<br>
>><br>
> <br>
> not intentionally.<br>
> I think theres 2 things youre noting:<br>
> <br>
> 1 - make frag into gvt/Makefile<br>
> I had it there earlier, not sure why I moved it up.<br>
> maybe some confusion on proper scope of the flag.<br>
> <br>
> <br>
> 2 - move new declaration code in i915-param.c inside the gvt ifdef<br>
> <br>
> Im good with that.<br>
> I'll probably copy the ifdef wrapper down rather than move the decl up.<br>
> ie:<br>
> <br>
> #if __and(IS_ENABLED(CONFIG_DRM_I915_GVT),<br>
> IS_ENABLED(CONFIG_DRM_USE_DYNAMIC_DEBUG))<br>
> <br>
> unsigned long __gvt_debug;<br>
> EXPORT_SYMBOL(__gvt_debug);<br>
> <br>
> <br>
>>> +<br>
>>> # Please keep these build lists sorted!<br>
>>><br>
>>> # core driver code<br>
>>> diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c<br>
>>> index e07f4cfea63a..e645e149485e 100644<br>
>>> --- a/drivers/gpu/drm/i915/i915_params.c<br>
>>> +++ b/drivers/gpu/drm/i915/i915_params.c<br>
>>> @@ -265,3 +265,38 @@ void i915_params_free(struct i915_params *params)<br>>>> + _DD_cat_("gvt:mmio:"),<br>
>>> + _DD_cat_("gvt:render:"),<br>
>>> + _DD_cat_("gvt:sched:"));<br>
>>> +<br>
>>> +#endif<br>
>><br>
>> So just the foundation - no actual use sites I mean? How would these be<br>
>> used from the code?<br>
>><br>
> <br>
> there are 120 pr_debug "users" :-)<br>
> <br>
> no users per se, but anyone using drm.debug<br>
> /sys/module/drm/parameters/debug<br>
> might use this too.<br>
> its a bit easier than composing queries for >/proc/dyamic_debug/control<br>
<br>
Same as my previous question, perhaps I am not up to speed with this <br>
yet.. Even if pr_debug is used inside GVT - are the categories and <br>
debug_gvt global as of this patch (or series)?<br>
<br></blockquote><div><br></div><div>they are already global in the sense that if kernel is built with DYNAMIC_DEBUG,</div><div>the admin can turn those pr_debugs on and off, and change their decorations in the log (mod,func.line).</div><div>Nor are modules protected from each other; drm-core could use dd-exec-queries to enable/disable</div><div>pr-debugs in i915 etc</div><div><br></div><div>This patch just adds a gvt-debug knob like drm-debug. using the existing format prefixes to categorize them.</div><div>Whether those prefixes should be bent towards consistency with the rest of drm-debug</div><div>or adapted towards some gvt community need I couldnt say.</div><div><br></div><div>Its no save-the-world feature, but its pretty cheap.</div><div><br></div><div>Id expect the same users as those who play with drm.debug, for similar reasons.</div><div><br></div><div>does this clarify ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards,<br>
<br>
Tvrtko<br></blockquote><div><br></div><div>thanks,</div><div>Jim </div></div></div>