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

[yanwang]

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.
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
>