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