On 4/19/2018 2:39 PM, yanwang wrote:
On Thu, 2018-04-12 at 16:07 +0100, Liam Girdwood wrote:
On Thu, 2018-04-12 at 22:48 +0800, Yan Wang wrote:
On 4/12/2018 10:14 PM, Liam Girdwood wrote:
On Thu, 2018-04-12 at 15:46 +0800, yan.wang@linux.intel.com wrote:
From: Yan Wang yan.wang@linux.intel.com
Implement DMA trace level based on modules. User can switch on/off for DMA trace of one module.
Are there any updates to userspace rmbox tools to use this feature ?
No currently. IMHO, we could use "echo/cat /sys/kernel/debug/sof/trace_level" to control it. So need I also add another control path to control it by rmbox? Thanks.
yeah, we could have a debugFS file "trace_control" and we would send :-
echo "VOL1.1:pipeline:2"
format is component:class:level
This would set trace to level 2 on component "VOL1.1" for pipeline operations
cat trace_control
would list each widget and the trace level for that widget.
Hi, Liam, I did some investigation on trace level for widget/component and initial implementation. On kernel side, I iterate sdev->widget_list to get widget name and component id for trace level. The component id can be used as index for component searching. There is also no problem to transfer trace level by IPC based on component id. On firmware side, I add variable into struct comp_dev for saving trace level for every loaded component. But there are 2 possible issues:
- Current trace macro doesn't include component id in audio
component implementation like src/audio/(src.c, host.c, ...). For trace level switch, I may have to change all existed trace with component id. 2. Not all functions of audio component include struct comp_dev as input parameter. E.g. src_buffer_lengths() in src/audo/src.c. For bind to component id, its input parameter may have to be changed. It is possible to load multiply same widgets in one pipeline. So global variable may not cover this issue. I am not sure whether the above 2 requests are acceptable. Or may there be better solution for this?
Hi, Liam, Could you please give some comments about my question? Thanks.
Yan Wang
Thanks.
Yan Wang
Liam
Yan Wang
Liam
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar e
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware