From: yakui_zhao <yak...@in...> - 2009-05-15 06:58:28
|
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. Signed-off-by: Zhao Yakui <yak...@in...> --- drivers/gpu/drm/drm_stub.c | 14 ++++++++++++++ include/drm/drmP.h | 36 +++++++++++++++++++++++++++++++----- 2 files changed, 45 insertions(+), 5 deletions(-) Index: linux-2.6/drivers/gpu/drm/drm_stub.c =================================================================== --- linux-2.6.orig/drivers/gpu/drm/drm_stub.c 2009-05-15 13:53:06.000000000 +0800 +++ linux-2.6/drivers/gpu/drm/drm_stub.c 2009-05-15 13:56:07.000000000 +0800 @@ -51,7 +51,21 @@ struct class *drm_class; struct proc_dir_entry *drm_proc_root; struct dentry *drm_debugfs_root; +void drm_ut_debug_printk(unsigned int request_level, + const char *prefix, + const char *function_name, + const char *format, ...) +{ + va_list args; + if (drm_debug & request_level) { + printk(KERN_DEBUG "[%s:%s] ,", prefix, function_name); + va_start(args, format); + printk(format, args); + va_end(args); + } +} +EXPORT_SYMBOL(drm_ut_debug_printk); static int drm_minor_get_id(struct drm_device *dev, int type) { int new_id; Index: linux-2.6/include/drm/drmP.h =================================================================== --- linux-2.6.orig/include/drm/drmP.h 2009-04-16 16:10:40.000000000 +0800 +++ linux-2.6/include/drm/drmP.h 2009-05-15 14:40:02.000000000 +0800 @@ -87,6 +87,15 @@ #include "drm_os_linux.h" #include "drm_hashtab.h" +#define DRM_UT_CORE 0x01 +#define DRM_UT_DRIVER 0x02 +#define DRM_UT_KMS 0x04 +#define DRM_UT_MODE 0x08 + +extern void drm_ut_debug_printk(unsigned int request_level, + const char *prefix, + const char *function_name, + const char *format, ...); /***********************************************************************/ /** \name DRM template customization defaults */ /*@{*/ @@ -186,14 +195,31 @@ * \param arg arguments */ #if DRM_DEBUG_CODE -#define DRM_DEBUG(fmt, arg...) \ +#define DRM_DEBUG(fmt, args...) \ do { \ - if ( drm_debug ) \ - printk(KERN_DEBUG \ - "[" DRM_NAME ":%s] " fmt , \ - __func__ , ##arg); \ + drm_ut_debug_printk(DRM_UT_CORE, DRM_NAME, \ + __func__, fmt, ##args); \ + } while (0) + +#define DRM_DEBUG_DRIVER(prefix, fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_DRIVER, prefix, \ + __func__, fmt, ##args); \ + } while (0) +#define DRM_DEBUG_KMS(prefix, fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_KMS, prefix, \ + __func__, fmt, ##args); \ + } while (0) +#define DRM_DEBUG_MODE(prefix, fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_MODE, prefix, \ + __func__, fmt, ##args); \ } while (0) #else +#define DRM_DEBUG_DRIVER(prefix, fmt, args...) do { } while (0) +#define DRM_DEBUG_KMS(prefix, fmt, args...) do { } while (0) +#define DRM_DEBUG_MODE(prefix, fmt, args...) do { } while (0) #define DRM_DEBUG(fmt, arg...) do { } while (0) #endif |
From: Dave A. <ai...@gm...> - 2009-05-15 09:24:21
|
> 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. Dave. > > Signed-off-by: Zhao Yakui <yak...@in...> > --- > drivers/gpu/drm/drm_stub.c | 14 ++++++++++++++ > include/drm/drmP.h | 36 +++++++++++++++++++++++++++++++----- > 2 files changed, 45 insertions(+), 5 deletions(-) > > Index: linux-2.6/drivers/gpu/drm/drm_stub.c > =================================================================== > --- linux-2.6.orig/drivers/gpu/drm/drm_stub.c 2009-05-15 13:53:06.000000000 +0800 > +++ linux-2.6/drivers/gpu/drm/drm_stub.c 2009-05-15 13:56:07.000000000 +0800 > @@ -51,7 +51,21 @@ > struct class *drm_class; > struct proc_dir_entry *drm_proc_root; > struct dentry *drm_debugfs_root; > +void drm_ut_debug_printk(unsigned int request_level, > + const char *prefix, > + const char *function_name, > + const char *format, ...) > +{ > + va_list args; > > + if (drm_debug & request_level) { > + printk(KERN_DEBUG "[%s:%s] ,", prefix, function_name); > + va_start(args, format); > + printk(format, args); > + va_end(args); > + } > +} > +EXPORT_SYMBOL(drm_ut_debug_printk); > static int drm_minor_get_id(struct drm_device *dev, int type) > { > int new_id; > Index: linux-2.6/include/drm/drmP.h > =================================================================== > --- linux-2.6.orig/include/drm/drmP.h 2009-04-16 16:10:40.000000000 +0800 > +++ linux-2.6/include/drm/drmP.h 2009-05-15 14:40:02.000000000 +0800 > @@ -87,6 +87,15 @@ > #include "drm_os_linux.h" > #include "drm_hashtab.h" > > +#define DRM_UT_CORE 0x01 > +#define DRM_UT_DRIVER 0x02 > +#define DRM_UT_KMS 0x04 > +#define DRM_UT_MODE 0x08 > + > +extern void drm_ut_debug_printk(unsigned int request_level, > + const char *prefix, > + const char *function_name, > + const char *format, ...); > /***********************************************************************/ > /** \name DRM template customization defaults */ > /*@{*/ > @@ -186,14 +195,31 @@ > * \param arg arguments > */ > #if DRM_DEBUG_CODE > -#define DRM_DEBUG(fmt, arg...) \ > +#define DRM_DEBUG(fmt, args...) \ > do { \ > - if ( drm_debug ) \ > - printk(KERN_DEBUG \ > - "[" DRM_NAME ":%s] " fmt , \ > - __func__ , ##arg); \ > + drm_ut_debug_printk(DRM_UT_CORE, DRM_NAME, \ > + __func__, fmt, ##args); \ > + } while (0) > + > +#define DRM_DEBUG_DRIVER(prefix, fmt, args...) \ > + do { \ > + drm_ut_debug_printk(DRM_UT_DRIVER, prefix, \ > + __func__, fmt, ##args); \ > + } while (0) > +#define DRM_DEBUG_KMS(prefix, fmt, args...) \ > + do { \ > + drm_ut_debug_printk(DRM_UT_KMS, prefix, \ > + __func__, fmt, ##args); \ > + } while (0) > +#define DRM_DEBUG_MODE(prefix, fmt, args...) \ > + do { \ > + drm_ut_debug_printk(DRM_UT_MODE, prefix, \ > + __func__, fmt, ##args); \ > } while (0) > #else > +#define DRM_DEBUG_DRIVER(prefix, fmt, args...) do { } while (0) > +#define DRM_DEBUG_KMS(prefix, fmt, args...) do { } while (0) > +#define DRM_DEBUG_MODE(prefix, fmt, args...) do { } while (0) > #define DRM_DEBUG(fmt, arg...) do { } while (0) > #endif > > > > _______________________________________________ > Intel-gfx mailing list > Int...@li... > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > |
From: yakui_zhao <yak...@in...> - 2009-05-18 02:30:11
|
On Fri, 2009-05-15 at 17:21 +0800, Dave Airlie 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. It will be helpful to get some the debug info in KMS mode as what we have done in UMS mode. For example: the SDVO command, the initialization of output device. In UMS mode the debug info is logged into the log file. In KMS mode we have to print the debug info in kernel space and get it in user space. To do so, we have two ways. One is to use the printk and separate the different DRM debug levels. Another is to allocate a buffer in kernel, which is used to record the info related with KMS. But this will be more complex and we will have to create an I/F to read the info in user space. > 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. > > Dave. > > > > > Signed-off-by: Zhao Yakui <yak...@in...> > > --- > > drivers/gpu/drm/drm_stub.c | 14 ++++++++++++++ > > include/drm/drmP.h | 36 +++++++++++++++++++++++++++++++----- > > 2 files changed, 45 insertions(+), 5 deletions(-) > > > > Index: linux-2.6/drivers/gpu/drm/drm_stub.c > > =================================================================== > > --- linux-2.6.orig/drivers/gpu/drm/drm_stub.c 2009-05-15 13:53:06.000000000 +0800 > > +++ linux-2.6/drivers/gpu/drm/drm_stub.c 2009-05-15 13:56:07.000000000 +0800 > > @@ -51,7 +51,21 @@ > > struct class *drm_class; > > struct proc_dir_entry *drm_proc_root; > > struct dentry *drm_debugfs_root; > > +void drm_ut_debug_printk(unsigned int request_level, > > + const char *prefix, > > + const char *function_name, > > + const char *format, ...) > > +{ > > + va_list args; > > > > + if (drm_debug & request_level) { > > + printk(KERN_DEBUG "[%s:%s] ,", prefix, function_name); > > + va_start(args, format); > > + printk(format, args); > > + va_end(args); > > + } > > +} > > +EXPORT_SYMBOL(drm_ut_debug_printk); > > static int drm_minor_get_id(struct drm_device *dev, int type) > > { > > int new_id; > > Index: linux-2.6/include/drm/drmP.h > > =================================================================== > > --- linux-2.6.orig/include/drm/drmP.h 2009-04-16 16:10:40.000000000 +0800 > > +++ linux-2.6/include/drm/drmP.h 2009-05-15 14:40:02.000000000 +0800 > > @@ -87,6 +87,15 @@ > > #include "drm_os_linux.h" > > #include "drm_hashtab.h" > > > > +#define DRM_UT_CORE 0x01 > > +#define DRM_UT_DRIVER 0x02 > > +#define DRM_UT_KMS 0x04 > > +#define DRM_UT_MODE 0x08 > > + > > +extern void drm_ut_debug_printk(unsigned int request_level, > > + const char *prefix, > > + const char *function_name, > > + const char *format, ...); > > /***********************************************************************/ > > /** \name DRM template customization defaults */ > > /*@{*/ > > @@ -186,14 +195,31 @@ > > * \param arg arguments > > */ > > #if DRM_DEBUG_CODE > > -#define DRM_DEBUG(fmt, arg...) \ > > +#define DRM_DEBUG(fmt, args...) \ > > do { \ > > - if ( drm_debug ) \ > > - printk(KERN_DEBUG \ > > - "[" DRM_NAME ":%s] " fmt , \ > > - __func__ , ##arg); \ > > + drm_ut_debug_printk(DRM_UT_CORE, DRM_NAME, \ > > + __func__, fmt, ##args); \ > > + } while (0) > > + > > +#define DRM_DEBUG_DRIVER(prefix, fmt, args...) \ > > + do { \ > > + drm_ut_debug_printk(DRM_UT_DRIVER, prefix, \ > > + __func__, fmt, ##args); \ > > + } while (0) > > +#define DRM_DEBUG_KMS(prefix, fmt, args...) \ > > + do { \ > > + drm_ut_debug_printk(DRM_UT_KMS, prefix, \ > > + __func__, fmt, ##args); \ > > + } while (0) > > +#define DRM_DEBUG_MODE(prefix, fmt, args...) \ > > + do { \ > > + drm_ut_debug_printk(DRM_UT_MODE, prefix, \ > > + __func__, fmt, ##args); \ > > } while (0) > > #else > > +#define DRM_DEBUG_DRIVER(prefix, fmt, args...) do { } while (0) > > +#define DRM_DEBUG_KMS(prefix, fmt, args...) do { } while (0) > > +#define DRM_DEBUG_MODE(prefix, fmt, args...) do { } while (0) > > #define DRM_DEBUG(fmt, arg...) do { } while (0) > > #endif > > > > > > > > _______________________________________________ > > Intel-gfx mailing list > > Int...@li... > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > |
From: Jesse B. <jb...@vi...> - 2009-05-27 15:28:20
|
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. Jesse |
From: yakui_zhao <yak...@in...> - 2009-05-31 01:26:13
|
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. Thanks. > > Jesse |
From: Jesse B. <jb...@vi...> - 2009-05-31 10:40:25
|
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 |
From: yakui_zhao <yak...@in...> - 2009-06-02 06:06:39
|
Hi, When the X is started in UMS mode, we can see the info related with the mode setting in the Xorg.log(For example: SDVO device command, modeline validation). This is very helpful to analyze the issue related with modesetting. When KMS is used, we have no such info. Maybe it is very useful that we can get such info in KMS mode. For example: adding the debug info by using the DRM_DEBUG macro definition. Now all the DRM debug info will be reported if the boot option of "drm.debug=1" is added. Sometimes it is inconvenient to get the debug info in KMS mode. We will get too much unrelated info. For example: drm ioctl info. The following patch set is to add several different debug level for DRM. The debug level can be used to print the different debug info.For example: The DRM_CORE level can be used to print the debug info related with drm ioctl. The debug level is controlled by the drm_debug module parameter. It can be changed by adding the boot option or drm module parameter I/F. Patch 1/5: Separate the different DRM debug levels. In the patch four debug levels are defined. DRM_CORE, DRIVER, KMS, MODE Patch 2/5: Replace the DRM_DEBUG with DRM_DEBUG_KMS to print the info in intel_lvds Patch 3/5: Replace the DrM_DEBUG with DRM_DEBUG_KMS to print the debug info in intel_sdvo Patch 4/5: Replace the DRM_DEBUG with DRM_DEBUG_MODE to print the debug info in drm_mode Patch 5/5: Replace the DRM_DEBUG with DRM_DEBUG_DRIVER to print the debug info in i915 driver. Welcome the comments. Thanks. |
From: yakui_zhao <yak...@in...> - 2009-06-09 02:27:05
|
On Tue, 2009-06-02 at 14:07 +0800, yakui_zhao wrote: > Hi, Hi, Any comments on this patch set? Is it convenient to get the debug info in KMS mode? Thanks. > When the X is started in UMS mode, we can see the info related with the mode > setting in the Xorg.log(For example: SDVO device command, modeline validation). > This is very helpful to analyze the issue related with modesetting. > When KMS is used, we have no such info. Maybe it is very useful that > we can get such info in KMS mode. For example: adding the debug info by > using the DRM_DEBUG macro definition. > > Now all the DRM debug info will be reported if the boot option of > "drm.debug=1" is added. Sometimes it is inconvenient to get the debug > info in KMS mode. We will get too much unrelated info. For example: drm > ioctl info. > > The following patch set is to add several different debug level for > DRM. The debug level can be used to print the different debug info.For > example: The DRM_CORE level can be used to print the debug info related > with drm ioctl. The debug level is controlled by the drm_debug module > parameter. It can be changed by adding the boot option or drm module > parameter I/F. > > > Patch 1/5: Separate the different DRM debug levels. > In the patch four debug levels are defined. DRM_CORE, > DRIVER, KMS, MODE > Patch 2/5: Replace the DRM_DEBUG with DRM_DEBUG_KMS to print the > info in intel_lvds > > Patch 3/5: Replace the DrM_DEBUG with DRM_DEBUG_KMS to print the > debug info in intel_sdvo > > Patch 4/5: Replace the DRM_DEBUG with DRM_DEBUG_MODE to print the > debug info in drm_mode > > Patch 5/5: Replace the DRM_DEBUG with DRM_DEBUG_DRIVER to print the > debug info in i915 driver. > > Welcome the comments. > > Thanks. > > > _______________________________________________ > Intel-gfx mailing list > Int...@li... > http://lists.freedesktop.org/mailman/listinfo/intel-gfx |
From: Jesse B. <jb...@vi...> - 2009-06-09 22:21:04
|
On Tue, 09 Jun 2009 10:28:08 +0800 yakui_zhao <yak...@in...> wrote: > On Tue, 2009-06-02 at 14:07 +0800, yakui_zhao wrote: > > Hi, > Hi, > Any comments on this patch set? > Is it convenient to get the debug info in KMS mode? > > Thanks. Yeah seems like a good idea to me. I think Dave will have to make the call. Acked-by: Jesse Barnes <jb...@vi...> |
From: yakui_zhao <yak...@in...> - 2009-06-02 06:08:35
|
Now all the DRM debug info will be reported if the boot option of "drm.debug=1" is added. Sometimes it is inconvenient to get the debug info in KMS mode. 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 we can get the different debug info by changing the debug level. This can be done by adding the module parameter. Of course it can be changed through the /sys/module/drm/parameters/debug after the system is booted. 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=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/DRM_DEBUG_DRIVER. Sometimes we expect to print the value of an array. For example: SDVO command, In such case the following four DRM debug macro definitions are added: DRM_LOG(fmt, args...) DRM_LOG_DRIVER(fmt, args...) DRM_LOG_KMS(fmt, args...) DRM_LOG_MODE(fmt, args...) Signed-off-by: Zhao Yakui <yak...@in...> --- drivers/gpu/drm/drm_stub.c | 17 +++++++++++- include/drm/drmP.h | 61 +++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 72 insertions(+), 6 deletions(-) Index: linux-2.6/drivers/gpu/drm/drm_stub.c =================================================================== --- linux-2.6.orig/drivers/gpu/drm/drm_stub.c 2009-06-02 13:14:19.000000000 +0800 +++ linux-2.6/drivers/gpu/drm/drm_stub.c 2009-06-02 13:26:35.000000000 +0800 @@ -51,7 +51,22 @@ struct class *drm_class; struct proc_dir_entry *drm_proc_root; struct dentry *drm_debugfs_root; - +void drm_ut_debug_printk(unsigned int request_level, + const char *prefix, + const char *function_name, + const char *format, ...) +{ + va_list args; + + if (drm_debug & request_level) { + if (function_name) + printk(KERN_DEBUG "[%s:%s], ", prefix, function_name); + va_start(args, format); + vprintk(format, args); + va_end(args); + } +} +EXPORT_SYMBOL(drm_ut_debug_printk); static int drm_minor_get_id(struct drm_device *dev, int type) { int new_id; Index: linux-2.6/include/drm/drmP.h =================================================================== --- linux-2.6.orig/include/drm/drmP.h 2009-06-02 13:14:19.000000000 +0800 +++ linux-2.6/include/drm/drmP.h 2009-06-02 13:26:35.000000000 +0800 @@ -87,6 +87,15 @@ #include "drm_os_linux.h" #include "drm_hashtab.h" +#define DRM_UT_CORE 0x01 +#define DRM_UT_DRIVER 0x02 +#define DRM_UT_KMS 0x04 +#define DRM_UT_MODE 0x08 + +extern void drm_ut_debug_printk(unsigned int request_level, + const char *prefix, + const char *function_name, + const char *format, ...); /***********************************************************************/ /** \name DRM template customization defaults */ /*@{*/ @@ -186,15 +195,57 @@ * \param arg arguments */ #if DRM_DEBUG_CODE -#define DRM_DEBUG(fmt, arg...) \ +#define DRM_DEBUG(fmt, args...) \ do { \ - if ( drm_debug ) \ - printk(KERN_DEBUG \ - "[" DRM_NAME ":%s] " fmt , \ - __func__ , ##arg); \ + drm_ut_debug_printk(DRM_UT_CORE, DRM_NAME, \ + __func__, fmt, ##args); \ + } while (0) + +#define DRM_DEBUG_DRIVER(prefix, fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_DRIVER, prefix, \ + __func__, fmt, ##args); \ + } while (0) +#define DRM_DEBUG_KMS(prefix, fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_KMS, prefix, \ + __func__, fmt, ##args); \ + } while (0) +#define DRM_DEBUG_MODE(prefix, fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_MODE, prefix, \ + __func__, fmt, ##args); \ + } while (0) +#define DRM_LOG(fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_CORE, NULL, \ + NULL, fmt, ##args); \ + } while (0) +#define DRM_LOG_KMS(fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_KMS, NULL, \ + NULL, fmt, ##args); \ + } while (0) +#define DRM_LOG_MODE(fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_MODE, NULL, \ + NULL, fmt, ##args); \ + } while (0) +#define DRM_LOG_DRIVER(fmt, args...) \ + do { \ + drm_ut_debug_printk(DRM_UT_DRIVER, NULL, \ + NULL, fmt, ##args); \ } while (0) #else +#define DRM_DEBUG_DRIVER(prefix, fmt, args...) do { } while (0) +#define DRM_DEBUG_KMS(prefix, fmt, args...) do { } while (0) +#define DRM_DEBUG_MODE(prefix, fmt, args...) do { } while (0) #define DRM_DEBUG(fmt, arg...) do { } while (0) +#define DRM_LOG(fmt, arg...) do { } while (0) +#define DRM_LOG_KMS(fmt, args...) do { } while (0) +#define DRM_LOG_MODE(fmt, arg...) do { } while (0) +#define DRM_LOG_DRIVER(fmt, arg...) do { } while (0) + #endif #define DRM_PROC_LIMIT (PAGE_SIZE-80) |