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

[Lin, Mengdong]

> -----Original Message-----
> From: yanwang [mailto:yan.wang at 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 at intel.com>; sof-intel at eclists.intel
> > > .com
> > > Cc: Lu, Yang A <yang.a.lu at 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 at eclists.intel.com [mailto:sof-intel-
> > > request at eclists.intel.com] On Behalf Of Lin, Mengdong
> > > Sent: Friday, April 27, 2018 3:22 PM
> > > To: sof-intel at eclists.intel.com
> > > Cc: Lu, Yang A <yang.a.lu at 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
> >