Re: [Sound-open-firmware] Introduce a module parameter to configure SOF driver debug output?
cc the public mailing list.
-----Original Message----- From: Kumar, Abhijeet Sent: Friday, April 27, 2018 6:46 PM To: Lin, Mengdong mengdong.lin@intel.com; sof-intel@eclists.intel.com Cc: Lu, Yang A yang.a.lu@intel.com Subject: RE: Introduce a module parameter to configure SOF driver debug output?
Sorry for the +1 noise. :) But I really think the idea of supporting different debug levels is nice. And if others think that it is doable, then maybe I would love to contribute RFC patches.
Hi Pierre/Liam,
Would you like to share some advice? And if this is doable, how can we define the categories: IPC, PCM, TOPOLOGY, VIRTIO, DEV, DRIVER?
Then we may define some macro like: SND_SOF_DEBUG_IPC(dev, fmt, args...) SND_SOF_DEBUG_PCM(dev, fmt, args...) SND_SOF_DEBUG_TPLG(dev, fmt, args...) ... for topology ...
And we can also define category for different levels: SND_SOF_INFO_IPC SND_SOF_WARN_IPC SND_SOF_ERR_IPC ...
drm defines a module parameter 'debug' for user to specify the DRM debug mode when booting the kernel
And adding my two cents to it. DRM provides a sysfs as well to change the value of debug parameters at runtime. So it's not the always case of providing the debug level in kernel cmdline.
cat /sys/module/drm/parameters/debug
Yes. This is nice :-)
Thanks Mengdong
Warm Regards, Abhijeet
-----Original Message----- From: sof-intel-request@eclists.intel.com [mailto:sof-intel- request@eclists.intel.com] On Behalf Of Lin, Mengdong Sent: Friday, April 27, 2018 3:22 PM To: sof-intel@eclists.intel.com Cc: Lu, Yang A yang.a.lu@intel.com Subject: Introduce a module parameter to configure SOF driver debug output?
Hi,
Sorry for the long mail.
The kernel debug message from SOF driver can help us to debug issues and CI to provide hints for failed test cases. But it will be too much to output all of debug message by default.
So maybe we can try to manage SOF debug messages as drm does?
DRM is kernel gfx subsystem and Intel i915 driver is based on it. drm defines a module parameter 'debug' for user to specify the DRM debug mode when booting the kernel. The debug mode is actually a bit mask of different message categories. By setting a suitable debug mode, user or CI can make DRM driver output message of specified categories. Usually we use drm.debug=0x0e to get most important debug messages.
Maybe SOF driver can also define its categories for debug messages? If this is doable, we can do some RFC patch.
Here is how drm defines its debug mode in drivers/gpu/drm/drm_drv.c:
MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug category.\n" "\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n" "\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n" "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n" "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n" "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n" "\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n" "\t\tBit 7 (0x80) will enable LEASE messages (leasing code)"); module_param_named(debug, drm_debug, int, 0600);
void drm_dev_printk(const struct device *dev, const char *level, unsigned int category, const char *function_name, const char *prefix, const char *format, ...) { struct va_format vaf; va_list args;
if (category != DRM_UT_NONE && !(drm_debug & category)) return;
va_start(args, format); vaf.fmt = format; vaf.va = &args;
if (dev) dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix, &vaf); ...
}
Then base on this, it defines macros for outputting of different categories:
#define DRM_DEV_DEBUG(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \ ##args)
#define DRM_DEBUG(fmt, ...) \ drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "", \ fmt, ##args)
#define DRM_DEBUG_DRIVER(fmt, ...) \ drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_KMS(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, \ ##args)
Thanks Mengdong
On Fri, 2018-04-27 at 12:38 +0000, Lin, Mengdong wrote:
cc the public mailing list.
-----Original Message----- From: Kumar, Abhijeet Sent: Friday, April 27, 2018 6:46 PM To: Lin, Mengdong mengdong.lin@intel.com; sof-intel@eclists.intel .com Cc: Lu, Yang A yang.a.lu@intel.com Subject: RE: Introduce a module parameter to configure SOF driver debug output?
Sorry for the +1 noise. :) But I really think the idea of supporting different debug levels is nice. And if others think that it is doable, then maybe I would love to contribute RFC patches.
Hi Pierre/Liam,
Would you like to share some advice? And if this is doable, how can we define the categories: IPC, PCM, TOPOLOGY, VIRTIO, DEV, DRIVER?
Then we may define some macro like: SND_SOF_DEBUG_IPC(dev, fmt, args...) SND_SOF_DEBUG_PCM(dev, fmt, args...) SND_SOF_DEBUG_TPLG(dev, fmt, args...) ... for topology ...
And we can also define category for different levels: SND_SOF_INFO_IPC SND_SOF_WARN_IPC SND_SOF_ERR_IPC ...
drm defines a module parameter 'debug' for user to specify the DRM debug mode when booting the kernel
And adding my two cents to it. DRM provides a sysfs as well to change the value of debug parameters at runtime. So it's not the always case of providing the debug level in kernel cmdline.
cat /sys/module/drm/parameters/debug
Yes. This is nice :-)
It may use the same debugfs interface to control kernel side and fw side. Currently I implemented a interface for fw side like the following: cat /sys/kernel/debug/sof/trace_level irq >> 1 ipc >> 1 dma >> 1 ssp >> 1 wait >> 1 lock >> 1 mem >> 1 value >> 1 PIPELINE.2.SSP2.IN >> 1 SSP2.IN >> 1 BUF2.0 >> 1 PCM0C >> 0 PIPELINE.1.SSP2.OUT >> 1 SSP2.OUT >> 1 BUF1.0 >> 1 PCM0P >> 1
echo PCM0C 0 > /sys/kernel/debug/sof/trace_level will disable the trace of capture host component of fw pipeline.
It includes trace level for common trace (irq, ipc, dma, ssp, wait, lock, mem, value) and for component/widget based loaded topology. Common trace level control could be used for both kernel driver and fw side at the same time. And 0 is for no trace, 1 is for normal trace, 2 is for normal and verbose trace. I am waiting Liam's comfirmation for my questions which have been sent previously and finish the v2 patch set. I can also add this feature into it in the v2 patch set. Thanks.
Yan Wang
Thanks Mengdong
Warm Regards, Abhijeet
-----Original Message----- From: sof-intel-request@eclists.intel.com [mailto:sof-intel- request@eclists.intel.com] On Behalf Of Lin, Mengdong Sent: Friday, April 27, 2018 3:22 PM To: sof-intel@eclists.intel.com Cc: Lu, Yang A yang.a.lu@intel.com Subject: Introduce a module parameter to configure SOF driver debug output?
Hi,
Sorry for the long mail.
The kernel debug message from SOF driver can help us to debug issues and CI to provide hints for failed test cases. But it will be too much to output all of debug message by default.
So maybe we can try to manage SOF debug messages as drm does?
DRM is kernel gfx subsystem and Intel i915 driver is based on it. drm defines a module parameter 'debug' for user to specify the DRM debug mode when booting the kernel. The debug mode is actually a bit mask of different message categories. By setting a suitable debug mode, user or CI can make DRM driver output message of specified categories. Usually we use drm.debug=0x0e to get most important debug messages.
Maybe SOF driver can also define its categories for debug messages? If this is doable, we can do some RFC patch.
Here is how drm defines its debug mode in drivers/gpu/drm/drm_drv.c:
MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug category.\n" "\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n" "\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n" "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n" "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n" "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n" "\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n" "\t\tBit 7 (0x80) will enable LEASE messages (leasing code)"); module_param_named(debug, drm_debug, int, 0600);
void drm_dev_printk(const struct device *dev, const char *level, unsigned int category, const char *function_name, const char *prefix, const char *format, ...) { struct va_format vaf; va_list args;
if (category != DRM_UT_NONE && !(drm_debug & category)) return;
va_start(args, format); vaf.fmt = format; vaf.va = &args;
if (dev) dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix, &vaf); ...
}
Then base on this, it defines macros for outputting of different categories:
#define DRM_DEV_DEBUG(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \ ##args)
#define DRM_DEBUG(fmt, ...) \ drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "", \ fmt, ##args)
#define DRM_DEBUG_DRIVER(fmt, ...) \ drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_KMS(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, \ ##args)
Thanks Mengdong
-----Original Message----- From: yanwang [mailto:yan.wang@linux.intel.com] Sent: Saturday, April 28, 2018 2:50 PM
On Fri, 2018-04-27 at 12:38 +0000, Lin, Mengdong wrote:
cc the public mailing list.
-----Original Message----- From: Kumar, Abhijeet Sent: Friday, April 27, 2018 6:46 PM To: Lin, Mengdong mengdong.lin@intel.com; sof-intel@eclists.intel .com Cc: Lu, Yang A yang.a.lu@intel.com Subject: RE: Introduce a module parameter to configure SOF driver debug output?
Sorry for the +1 noise. :) But I really think the idea of supporting different debug levels is nice. And if others think that it is doable, then maybe I would love to contribute RFC patches.
Hi Pierre/Liam,
Would you like to share some advice? And if this is doable, how can we define the categories: IPC, PCM, TOPOLOGY, VIRTIO, DEV, DRIVER?
Then we may define some macro like: SND_SOF_DEBUG_IPC(dev, fmt, args...) SND_SOF_DEBUG_PCM(dev, fmt, args...) SND_SOF_DEBUG_TPLG(dev, fmt, args...) ... for topology ...
And we can also define category for different levels: SND_SOF_INFO_IPC SND_SOF_WARN_IPC SND_SOF_ERR_IPC ...
drm defines a module parameter 'debug' for user to specify the DRM debug mode when booting the kernel
And adding my two cents to it. DRM provides a sysfs as well to change the value of debug parameters at runtime. So it's not the always case of providing the debug level in kernel cmdline.
cat /sys/module/drm/parameters/debug
Yes. This is nice :-)
It may use the same debugfs interface to control kernel side and fw side. Currently I implemented a interface for fw side like the following: cat /sys/kernel/debug/sof/trace_level irq >> 1 ipc >> 1 dma >> 1 ssp >> 1 wait >> 1 lock >> 1 mem >> 1 value >> 1 PIPELINE.2.SSP2.IN >> 1 SSP2.IN >> 1 BUF2.0 >> 1 PCM0C >> 0 PIPELINE.1.SSP2.OUT >> 1 SSP2.OUT >> 1 BUF1.0 >> 1 PCM0P >> 1
echo PCM0C 0 > /sys/kernel/debug/sof/trace_level will disable the trace of capture host component of fw pipeline.
It includes trace level for common trace (irq, ipc, dma, ssp, wait, lock, mem, value) and for component/widget based loaded topology. Common trace level control could be used for both kernel driver and fw side at the same time.
Hi Yan,
I feel it would be nice but not necessary to use same debug interface or kernel module parameter to control both kernel debug message and FW trace output.
It's because the firmware components can be different from those of kernel driver. So we'd better not bind them together, and so users have the freedom to enable/disable either of them.
To control the kernel debug message, I hesitate to introduce multiple parameters if a single parameter "debug" can work.
Thanks Mengdong
And 0 is for no trace, 1 is for normal trace, 2 is for normal and verbose trace. I am waiting Liam's comfirmation for my questions which have been sent previously and finish the v2 patch set. I can also add this feature into it in the v2 patch set. Thanks.
Yan Wang
Thanks Mengdong
Warm Regards, Abhijeet
-----Original Message----- From: sof-intel-request@eclists.intel.com [mailto:sof-intel- request@eclists.intel.com] On Behalf Of Lin, Mengdong Sent: Friday, April 27, 2018 3:22 PM To: sof-intel@eclists.intel.com Cc: Lu, Yang A yang.a.lu@intel.com Subject: Introduce a module parameter to configure SOF driver debug output?
Hi,
Sorry for the long mail.
The kernel debug message from SOF driver can help us to debug issues and CI to provide hints for failed test cases. But it will be too much to output all of debug message by default.
So maybe we can try to manage SOF debug messages as drm does?
DRM is kernel gfx subsystem and Intel i915 driver is based on it. drm defines a module parameter 'debug' for user to specify the DRM debug mode when booting the kernel. The debug mode is actually a bit mask of different message categories. By setting a suitable debug mode, user or CI can make DRM driver output message of specified categories. Usually we use drm.debug=0x0e to get most important debug messages.
Maybe SOF driver can also define its categories for debug messages? If this is doable, we can do some RFC patch.
Here is how drm defines its debug mode in drivers/gpu/drm/drm_drv.c:
MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables
a debug category.\n" "\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n" "\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n" "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n" "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n" "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n" "\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n" "\t\tBit 7 (0x80) will enable LEASE messages (leasing code)"); module_param_named(debug, drm_debug, int, 0600);
void drm_dev_printk(const struct device *dev, const char *level, unsigned int category, const char *function_name, const char *prefix, const char *format, ...) { struct va_format vaf; va_list args;
if (category != DRM_UT_NONE && !(drm_debug & category)) return;
va_start(args, format); vaf.fmt = format; vaf.va = &args;
if (dev) dev_printk(level, dev, DRM_PRINTK_FMT, function_name,
prefix,
&vaf);...
}
Then base on this, it defines macros for outputting of different categories:
#define DRM_DEV_DEBUG(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \ ##args)
#define DRM_DEBUG(fmt, ...)
\ drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "", \ fmt, ##args)
#define DRM_DEBUG_DRIVER(fmt, ...)
\ drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_KMS(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, \ ##args)
Thanks Mengdong
echo PCM0C 0 > /sys/kernel/debug/sof/trace_level will disable the trace of capture host component of fw pipeline.
It includes trace level for common trace (irq, ipc, dma, ssp, wait, lock, mem, value) and for component/widget based loaded topology. Common trace level control could be used for both kernel driver and fw side at the same time.
Hi Yan,
I feel it would be nice but not necessary to use same debug interface or kernel module parameter to control both kernel debug message and FW trace output.
It's because the firmware components can be different from those of kernel driver. So we'd better not bind them together, and so users have the freedom to enable/disable either of them.
+1
To control the kernel debug message, I hesitate to introduce multiple parameters if a single parameter "debug" can work.
Thanks Mengdong
And 0 is for no trace, 1 is for normal trace, 2 is for normal and verbose trace. I am waiting Liam's comfirmation for my questions which have been sent previously and finish the v2 patch set. I can also add this feature into it in the v2 patch set. Thanks.
Yan Wang
Thanks Mengdong
Warm Regards, Abhijeet
-----Original Message----- From: sof-intel-request@eclists.intel.com [mailto:sof-intel- request@eclists.intel.com] On Behalf Of Lin, Mengdong Sent: Friday, April 27, 2018 3:22 PM To: sof-intel@eclists.intel.com Cc: Lu, Yang A yang.a.lu@intel.com Subject: Introduce a module parameter to configure SOF driver debug output?
Hi,
Sorry for the long mail.
The kernel debug message from SOF driver can help us to debug issues and CI to provide hints for failed test cases. But it will be too much to output all of debug message by default.
So maybe we can try to manage SOF debug messages as drm does?
DRM is kernel gfx subsystem and Intel i915 driver is based on it. drm defines a module parameter 'debug' for user to specify the DRM debug mode when booting the kernel. The debug mode is actually a bit mask of different message categories. By setting a suitable debug mode, user or CI can make DRM driver output message of specified categories. Usually we use drm.debug=0x0e to get most important debug messages.
Maybe SOF driver can also define its categories for debug messages? If this is doable, we can do some RFC patch.
Here is how drm defines its debug mode in drivers/gpu/drm/drm_drv.c:
MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables
a debug category.\n" "\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n" "\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n" "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n" "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n" "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n" "\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n" "\t\tBit 7 (0x80) will enable LEASE messages (leasing code)"); module_param_named(debug, drm_debug, int, 0600);
void drm_dev_printk(const struct device *dev, const char *level, unsigned int category, const char *function_name, const char *prefix, const char *format, ...) { struct va_format vaf; va_list args;
if (category != DRM_UT_NONE && !(drm_debug & category)) return;
va_start(args, format); vaf.fmt = format; vaf.va = &args;
if (dev) dev_printk(level, dev, DRM_PRINTK_FMT, function_name,
prefix,
&vaf);...
}
Then base on this, it defines macros for outputting of different categories:
#define DRM_DEV_DEBUG(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \ ##args)
#define DRM_DEBUG(fmt, ...)
\ drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "", \ fmt, ##args)
#define DRM_DEBUG_DRIVER(fmt, ...)
\ drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_KMS(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, \ ##args)
Thanks Mengdong
On 5/2/2018 9:15 PM, Pierre-Louis Bossart wrote:
echo PCM0C 0 > /sys/kernel/debug/sof/trace_level will disable the trace of capture host component of fw pipeline.
It includes trace level for common trace (irq, ipc, dma, ssp, wait, lock, mem, value) and for component/widget based loaded topology. Common trace level control could be used for both kernel driver and fw side at the same time.
Hi Yan,
I feel it would be nice but not necessary to use same debug interface or kernel module parameter to control both kernel debug message and FW trace output.
It's because the firmware components can be different from those of kernel driver. So we'd better not bind them together, and so users have the freedom to enable/disable either of them.
+1
Sure. I will refine firmware trace level based the latest comments from Liam at first. After this, I can try to add another trace control for kernel side. Thanks.
Yan Wang
To control the kernel debug message, I hesitate to introduce multiple parameters if a single parameter "debug" can work.
Thanks Mengdong
And 0 is for no trace, 1 is for normal trace, 2 is for normal and verbose trace. I am waiting Liam's comfirmation for my questions which have been sent previously and finish the v2 patch set. I can also add this feature into it in the v2 patch set. Thanks.
Yan Wang
Thanks Mengdong
Warm Regards, Abhijeet
-----Original Message----- From: sof-intel-request@eclists.intel.com [mailto:sof-intel- request@eclists.intel.com] On Behalf Of Lin, Mengdong Sent: Friday, April 27, 2018 3:22 PM To: sof-intel@eclists.intel.com Cc: Lu, Yang A yang.a.lu@intel.com Subject: Introduce a module parameter to configure SOF driver debug output?
Hi,
Sorry for the long mail.
The kernel debug message from SOF driver can help us to debug issues and CI to provide hints for failed test cases. But it will be too much to output all of debug message by default.
So maybe we can try to manage SOF debug messages as drm does?
DRM is kernel gfx subsystem and Intel i915 driver is based on it. drm defines a module parameter 'debug' for user to specify the DRM debug mode when booting the kernel. The debug mode is actually a bit mask of different message categories. By setting a suitable debug mode, user or CI can make DRM driver output message of specified categories. Usually we use drm.debug=0x0e to get most important debug messages.
Maybe SOF driver can also define its categories for debug messages? If this is doable, we can do some RFC patch.
Here is how drm defines its debug mode in drivers/gpu/drm/drm_drv.c:
MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables
a debug category.\n" "\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n" "\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n" "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n" "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n" "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n" "\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n" "\t\tBit 7 (0x80) will enable LEASE messages (leasing code)"); module_param_named(debug, drm_debug, int, 0600);
void drm_dev_printk(const struct device *dev, const char *level, unsigned int category, const char *function_name, const char *prefix, const char *format, ...) { struct va_format vaf; va_list args;
if (category != DRM_UT_NONE && !(drm_debug & category)) return;
va_start(args, format); vaf.fmt = format; vaf.va = &args;
if (dev) dev_printk(level, dev, DRM_PRINTK_FMT, function_name,
prefix,
&vaf); ...
}
Then base on this, it defines macros for outputting of different categories:
#define DRM_DEV_DEBUG(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \ ##args)
#define DRM_DEBUG(fmt, ...)
\ drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "", \ fmt, ##args)
#define DRM_DEBUG_DRIVER(fmt, ...)
\ drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
#define DRM_DEV_DEBUG_KMS(dev, fmt, args...) \ drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt, \ ##args)
Thanks Mengdong
participants (4)
-
Lin, Mengdong -
Pierre-Louis Bossart -
Yan Wang -
yanwang