On Wed, 2018-05-02 at 09:45 +0100, Liam Girdwood wrote:
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);
Yes. But current existed trace calling need be replaced by trace_comp()?
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.
Sure. I can fix it.
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.
Sure. Thanks.
Yan Wang
Liam
Hi, Liam, Could you please give some comments about my question? Thanks.
Yan Wang
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware