Re: [Intel-gfx] [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories

[jim.cromie@gmail.com]

[-- Attachment #1: Type: text/plain, Size: 8666 bytes --]

On Mon, Sep 6, 2021 at 6:26 AM Tvrtko Ursulin <
tvrtko.ursulin@linux.intel.com> wrote:
>
>
> On 03/09/2021 20:22, jim.cromie@gmail.com wrote:
> > On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin
> > <tvrtko.ursulin@linux.intel.com> wrote:
> >>
> >>
> >> On 31/08/2021 21:21, Jim Cromie wrote:
> >>> The gvt component of this driver has ~120 pr_debugs, in 9 categories
> >>> quite similar to those in DRM.  Following the interface model of
> >>> drm.debug, add a parameter to map bits to these categorizations.
> >>>
> >>> DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
> >>>        "dyndbg bitmap desc",
> >>>        { "gvt:cmd: ",  "command processing" },

> >>> v7:
> >>> . move ccflags addition up to i915/Makefile from i915/gvt
> >>> ---
> >>>    drivers/gpu/drm/i915/Makefile      |  4 ++++
> >>>    drivers/gpu/drm/i915/i915_params.c | 35
++++++++++++++++++++++++++++++
> >>
> >> Can this work if put under gvt/ or at least intel_gvt.h|c?

I tried this.
I moved the code block into gvt/debug.c (new file)
added it to Makefile GVT_SOURCES
dunno why it wont make.
frustratig basic err, Im not seeing.
It does seem proper placement, will resolve...


> >>
> >
> > I thought it belonged here more, at least according to the name of the
> > config.var
>
> Hmm bear with me please - the categories this patch creates are intended
> to be used explicitly from the GVT "sub-module", or they somehow even
> get automatically used with no further intervention to callers required?
>

2009 - v5.9.0  the only users were admins reading/echoing
/proc/dynamic_debug/control
presumably cuz they wanted more info in the logs, episodically.
v5.9.0 exported dynamic_debug_exec_queries for in-kernel use,
reusing the stringy: echo $query_command > control  idiom.
My intention was to let in-kernel users roll their own drm.debug type
interface,
or whatever else they needed.  nobodys using it yet.

patch 1/8 implements that drm.debug interface.
5/8 is the primary use case
3/8 (this patch) & 4/8 are patches of opportunity, test cases, proof of
function/utility.
its value as such is easier control of those pr-debugs than given by echo >
control

Sean Paul  seanpaul@chromium.org worked up a patchset to do runtime
steering of drm-debug stream,
in particular watching for drm:atomic:fail: type activity (a subcategory
which doesnt exist yet).
5/8 conflicts with his patchset, I have an rfc approach to that, so his
concerns are mine too.


note:  if this patchset goes in, we dont *really* need the export anymore,
since the main use case is covered.  We could un-export, and re-add later
if its needed for a different use case.  Further, it seems likely that the
callbacks
(refactored) would be a better basis for new in-kernel users.
If not that, then full exposure of struct ddebug_query to in-kernel use


not quite sure how we got 2 chunks, but theres 1 more q below.

On Mon, Sep 6, 2021 at 6:26 AM Tvrtko Ursulin <
tvrtko.ursulin@linux.intel.com> wrote:

>
> On 03/09/2021 20:22, jim.cromie@gmail.com wrote:
> > On Fri, Sep 3, 2021 at 5:07 AM Tvrtko Ursulin
> > <tvrtko.ursulin@linux.intel.com> wrote:
> >>
> >>
> >> On 31/08/2021 21:21, Jim Cromie wrote:
> >>> The gvt component of this driver has ~120 pr_debugs, in 9 categories
> >>> quite similar to those in DRM.  Following the interface model of
> >>> drm.debug, add a parameter to map bits to these categorizations.
> >>>
> >>> DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug,
> >>>        "dyndbg bitmap desc",
> >>>        { "gvt:cmd: ",  "command processing" },
> >>>        { "gvt:core: ", "core help" },
> >>>        { "gvt:dpy: ",  "display help" },
> >>>        { "gvt:el: ",   "help" },
> >>>        { "gvt:irq: ",  "help" },
> >>>        { "gvt:mm: ",   "help" },
> >>>        { "gvt:mmio: ", "help" },
> >>>        { "gvt:render: ", "help" },
> >>>        { "gvt:sched: " "help" });
> >>>
> >
> > BTW, Ive dropped the help field, its already handled, dont need to
> clutter.
> >
> >
> >>> The actual patch has a few details different, cmd_help() macro emits
> >>> the initialization construct.
> >>>
> >>> if CONFIG_DRM_USE_DYNAMIC_DEBUG, then -DDYNAMIC_DEBUG_MODULE is added
> >>> cflags, by gvt/Makefile.
> >>>
> >>> Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
> >>> ---
> >>> v5:
> >>> . static decl of vector of bit->class descriptors - Emil.V
> >>> . relocate gvt-makefile chunk from elsewhere
> >>> v7:
> >>> . move ccflags addition up to i915/Makefile from i915/gvt
> >>> ---
> >>>    drivers/gpu/drm/i915/Makefile      |  4 ++++
> >>>    drivers/gpu/drm/i915/i915_params.c | 35
> ++++++++++++++++++++++++++++++
> >>
> >> Can this work if put under gvt/ or at least intel_gvt.h|c?
> >>
> >
> > I thought it belonged here more, at least according to the name of the
> > config.var
>
> Hmm bear with me please - the categories this patch creates are intended
> to be used explicitly from the GVT "sub-module", or they somehow even
> get automatically used with no further intervention to callers required?
>
> > CONFIG_DRM_USE_DYNAMIC_DEBUG.
> >
> > I suppose its not a great name, its narrow purpose is to swap
> > drm-debug api to use dyndbg.   drm-evrything already "uses"
> > dyndbg if CONFIG_DYNAMIC_DEBUG=y, those gvt/pr_debugs in particular.
> >
> > Theres also CONFIG_DYNAMIC_DEBUG_CORE=y,
> > which drm basically ignores currently.
> >
> > So with the name CONFIG_DRM_USE_DYNAMIC_DEBUG
> > it seemed proper to arrange for that  to be true on DD-CORE=y builds,
> > by adding -DDYNAMIC_DEBUG_MODULE
> >
> > Does that make some sense ?
> > How to best resolve the frictions ?
> > new CONFIG names ?
> >
> >>>    2 files changed, 39 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> >>> index 4f22cac1c49b..5a4e371a3ec2 100644
> >>> --- a/drivers/gpu/drm/i915/Makefile
> >>> +++ b/drivers/gpu/drm/i915/Makefile
> >>> @@ -30,6 +30,10 @@ CFLAGS_display/intel_fbdev.o = $(call
> cc-disable-warning, override-init)
> >>>
> >>>    subdir-ccflags-y += -I$(srctree)/$(src)
> >>>
> >>> +#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
> >>> +ccflags-y += -DDYNAMIC_DEBUG_MODULE
> >>> +#endif
> >>
> >> Ignores whether CONFIG_DRM_I915_GVT is enabled or not?
> >>
> >
> > not intentionally.
> > I think theres 2 things youre noting:
> >
> > 1 - make frag into gvt/Makefile
> > I had it there earlier, not sure why I moved it up.
> > maybe some confusion on proper scope of the flag.
> >
> >
> > 2 - move new declaration code in i915-param.c inside the gvt ifdef
> >
> > Im good with that.
> > I'll probably copy the ifdef wrapper down rather than move the decl up.
> > ie:
> >
> > #if __and(IS_ENABLED(CONFIG_DRM_I915_GVT),
> >    IS_ENABLED(CONFIG_DRM_USE_DYNAMIC_DEBUG))
> >
> > unsigned long __gvt_debug;
> > EXPORT_SYMBOL(__gvt_debug);
> >
> >
> >>> +
> >>>    # Please keep these build lists sorted!
> >>>
> >>>    # core driver code
> >>> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> >>> index e07f4cfea63a..e645e149485e 100644
> >>> --- a/drivers/gpu/drm/i915/i915_params.c
> >>> +++ b/drivers/gpu/drm/i915/i915_params.c
> >>> @@ -265,3 +265,38 @@ void i915_params_free(struct i915_params *params)
> >>> +                             _DD_cat_("gvt:mmio:"),
> >>> +                             _DD_cat_("gvt:render:"),
> >>> +                             _DD_cat_("gvt:sched:"));
> >>> +
> >>> +#endif
> >>
> >> So just the foundation - no actual use sites I mean? How would these be
> >> used from the code?
> >>
> >
> > there are 120 pr_debug "users" :-)
> >
> > no users per se, but anyone using drm.debug
> > /sys/module/drm/parameters/debug
> > might use this too.
> > its a bit easier than composing queries for >/proc/dyamic_debug/control
>
> Same as my previous question, perhaps I am not up to speed with this
> yet.. Even if pr_debug is used inside GVT - are the categories and
> debug_gvt global as of this patch (or series)?
>
>
they are already global in the sense that if kernel is built with
DYNAMIC_DEBUG,
the admin can turn those pr_debugs on and off, and change their decorations
in the log (mod,func.line).
Nor are modules protected from each other; drm-core could use
dd-exec-queries to enable/disable
pr-debugs in i915 etc

This patch just adds a gvt-debug knob like drm-debug. using the existing
format prefixes to categorize them.
Whether those prefixes should be bent towards consistency with the rest of
drm-debug
or adapted towards some gvt community need I couldnt say.

Its no save-the-world feature, but its pretty cheap.

Id expect the same users as those who play with drm.debug, for similar
reasons.

does this clarify ?


> Regards,
>
> Tvrtko
>

thanks,
Jim

[-- Attachment #2: Type: text/html, Size: 11917 bytes --]