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

[yakui_zhao]

On Wed, 2009-05-27 at 23:28 +0800, Jesse Barnes wrote:
> On Fri, 15 May 2009 19:21:40 +1000
> Dave Airlie <airlied at gmail.com> 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.

Thanks.

> 
> Jesse