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

[Yan Wang]

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