Re: [Intel-gfx] [RFC] [Patch] [DRM] :Separate several DRM debug levels
On Wed, 2009-05-27 at 23:28 +0800, Jesse Barnes wrote: On Fri, 15 May 2009 19:21:40 +1000 Dave Airlie airl...@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 -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] [Patch] [DRM] :Separate several DRM debug levels
On Sun, 31 May 2009 09:27:54 +0800 yakui_zhao yakui.z...@intel.com wrote: On Wed, 2009-05-27 at 23:28 +0800, Jesse Barnes wrote: On Fri, 15 May 2009 19:21:40 +1000 Dave Airlie airl...@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. 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 -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] [Patch] [DRM] :Separate several DRM debug levels
On Fri, 15 May 2009 19:21:40 +1000 Dave Airlie airl...@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. Jesse -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] [Patch] [DRM] :Separate several DRM debug levels
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 yakui.z...@intel.com
---
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.0 +0800
+++ linux-2.6/drivers/gpu/drm/drm_stub.c2009-05-15
13:56:07.0 +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.0 +0800
+++ linux-2.6/include/drm/drmP.h2009-05-15 14:40:02.0 +0800
@@ -87,6 +87,15 @@
#include drm_os_linux.h
#include drm_hashtab.h
+#define DRM_UT_CORE0x01
+#define DRM_UT_DRIVER 0x02
+#define DRM_UT_KMS 0x04
+#define DRM_UT_MODE0x08
+
+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
Re: [Intel-gfx] [RFC] [Patch] [DRM] :Separate several DRM debug levels
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 yakui.z...@intel.com
---
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.0
+0800
+++ linux-2.6/drivers/gpu/drm/drm_stub.c 2009-05-15 13:56:07.0
+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.0 +0800
+++ linux-2.6/include/drm/drmP.h 2009-05-15 14:40:02.0 +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 { \
+
