[Sound-open-firmware] Introduce a module parameter to configure SOF driver debug output?

[Pierre-Louis Bossart]

On 4/27/18 5:05 AM, Lin, Mengdong wrote:
> 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 a debug mask when booting the kernel. The debug mask is a bit mask of different message categories. By setting a suitable mask, 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 use this method to configure its 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)");

not a bad idea for developers. when folks debug topology or IPC stuff, 
they don't necessarily care about PCM or page tables, so it's a good way 
to filter. we could have one bit per module (core, pcm, ipc, topology, 
acpi, pci, etc).

I don't see how this improves CI work though?


> 
> 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
> 
> 
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>