Re: [Intel-gfx] [RFC] [Patch] [DRM] :Separate several DRM debug levels

[Jesse B. <jb...@vi...>]

On Sun, 31 May 2009 09:27:54 +0800
yakui_zhao <yak...@in...> wrote:

> On Wed, 2009-05-27 at 23:28 +0800, Jesse Barnes wrote:
> > On Fri, 15 May 2009 19:21:40 +1000
> > Dave Airlie <ai...@gm...> wrote:
> > 
> > > > Now all the DRM debug info will be printed if the boot option of
> > > > "drm.debug=1" is added. Sometimes it is inconvenient. We will
> > > > get too much unrelated info.
> > > >
> > > > This will separate several DRM debug levels and the debug level
> > > > can be used to print the different debug info. And the debug
> > > > level is controlled by the module parameter of drm.debug
> > > >        In this patch it is divided into four debug levels;
> > > >        drm_core, drm_driver, drm_kms, drm_mode.
> > > >
> > > > At the same time four debug macro definitions are provided.
> > > >        DRM_DEBUG(fmt, args...)
> > > >        DRM_DEBUG_DRIVER(prefix, fmt, args...)
> > > >        DRM_DEBUG_KMS(prefix, fmt, args...)
> > > >        DRM_DEBUG_MODE(prefix, fmt, args...)
> > > >
> > > > When the boot option of "drm.debug=1" is added, it will print
> > > > the debug info using DRM_DEBUG. This is to be compatible with
> > > > When the boot option of "drm.debug=4" is added, it will print
> > > > the debug info using DRM_DEBUG_KMS macro definition.
> > > > When the boot option of "drm.debug=6" is added, it will print
> > > > the debug info using DRM_DEBUG_KMS and DRM_DEBUG_DRIVE.
> > > >
> > > > When the DRM_DEBUG is used, the default prefix is "drm".
> > > > When the DRM_DEBUG_DRIVER/KMS/MODE is used, we can use the
> > > > different prefix. For example: When DRM_DEBUG_KMS is used in the
> > > > drivers/gpu/drm/i915/intel_lvds.c, we can use the "i915_lvds" as
> > > > the prefix.
> > > >
> > > 
> > > I'm just wondering if we can leverage the kernel debug printing
> > > stuff for all this, I like the idea of what
> > > you are trying to do alright, its crazy trying to debug using the
> > > current single path.
> > > 
> > > I'm on holidays so can't review too much, but I'd like to see
> > > people discuss the kernel debug printing
> > > system and also the split between debug categories.
> > 
> > Yeah it would be good if the kernel could handle this, but it
> > doesn't seem like the generic debug code will do what we want.  We
> > can enable debug on a by-module basis or hide things with pr_debug,
> > but I didn't (in my quick scan) see a way of defining subsystem
> > flags for debug options.  Hopefully I'm wrong though...  Yakui,
> > have you looked at all?  Maybe it would be better to make your
> > patches improve the pr_debug stuff instead, allowing drivers &
> > subsystems to register different types of debug info (probably with
> > just a bitmask) and filter things that way.
> The macro definition of pr_debug can also print what we want. But it
> is controlled by kernel compilation option(For example: add the DEBUG
> definition in Makefile). It is not very convenient. At the same time
> all debug info will be printed together. 
> 
> Several subsystems use the way of defining different levels for debug
> options. For example: cpufreq, acpi. In the acpi subsystem not only
> the different levels are defined, but also the different components
> are defined. And after the system is booted, we can change the debug
> level to print the info what we wanted.
> 
> It is a very good point to improve the pr_debug stuff by allowing
> drivers & subsystem to register the different types of debug info. 
> But it seems that it will be complex. In fact many subsystems have
> their own debug ways. I am not sure whether it is valuable by adding
> this. Maybe it is enough to print what we wanted by dividing
> different debug levels.

Yeah, we should probably just add something like your simple patch to
DRM now.  If you feel ambitious you could then add core kernel code for
this and fixup the callers. :)

I wonder if the flags should also have a driver specific set.  If you
look at GEM, there are lot of different bits of info we could convert
that way.  But at a minimum I'd like to see KMS vs DRIVER flags to
separate out output configuration stuff from the flood of ioctls we get.

Thanks,
Jesse