Messages in this thread | | | Subject | Re: [Intel-gfx] [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories | From | Tvrtko Ursulin <> | Date | Mon, 6 Sep 2021 13:26:23 +0100 |
| |
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) >>> I915_PARAMS_FOR_EACH(FREE); >>> #undef FREE >>> } >>> + >>> +#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG >>> +/* todo: needs DYNAMIC_DEBUG_MODULE in some cases */ >>> + >>> +unsigned long __gvt_debug; >>> +EXPORT_SYMBOL(__gvt_debug); >>> + >>> +#define _help(key) "\t \"" key "\"\t: help for " key "\n" >>> + >>> +#define I915_GVT_CATEGORIES(name) \ >>> + " Enable debug output via /sys/module/i915/parameters/" #name \ >>> + ", where each bit enables a debug category.\n" \ >>> + _help("gvt:cmd:") \ >>> + _help("gvt:core:") \ >>> + _help("gvt:dpy:") \ >>> + _help("gvt:el:") \ >>> + _help("gvt:irq:") \ >>> + _help("gvt:mm:") \ >>> + _help("gvt:mmio:") \ >>> + _help("gvt:render:") \ >>> + _help("gvt:sched:") >>> + >>> +DEFINE_DYNAMIC_DEBUG_CATEGORIES(debug_gvt, __gvt_debug, >>> + I915_GVT_CATEGORIES(debug_gvt), >>> + _DD_cat_("gvt:cmd:"), >>> + _DD_cat_("gvt:core:"), >>> + _DD_cat_("gvt:dpy:"), >>> + _DD_cat_("gvt:el:"), >>> + _DD_cat_("gvt:irq:"), >>> + _DD_cat_("gvt:mm:"), >>> + _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)?
Regards,
Tvrtko
| |