[Sound-open-firmware] [PATCH 0/2] DMA trace level

[yanwang]

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 at linux.intel.com
> > > wrote:
> > > > 
> > > > From: Yan Wang <yan.wang at 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:
	1. 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?
	Thanks.

Yan Wang

		
> 
> Liam
> 
> > 
> > Yan Wang
> > 
> > > 
> > > 
> > > Liam
> > > 
> > 
> > _______________________________________________
> > Sound-open-firmware mailing list
> > Sound-open-firmware at alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar
> > e