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

Liam Girdwood liam.r.girdwood at linux.intel.com
Wed May 2 10:45:34 CEST 2018


On Wed, 2018-04-25 at 13:31 +0800, Yan Wang wrote:
> > 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.

Add uint32_t trace_level to every component. This will be set/enabled by trace
IPC from host.

then in trace.h

#define trace_comp(comp_dev, level, trace_data) \
	if (comp_dev->trace_level >= level) \
		emit_trace(data);
 

> >        2. Not all functions of audio component include struct comp_dev
> > as input parameter. E.g. src_buffer_lengths() in src/audo/src.c.

best to fix them.

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

For non components, a similar local uint32_t trace_level  can be added and set
by IPC and in cases where we cannot yet use a local trace_level then we can use
a global trace_level.

Liam

> 
> Hi, Liam,
>         Could you please give some comments about my question?
>         Thanks.
> 
> Yan Wang


More information about the Sound-open-firmware mailing list