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

[Yan Wang]

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

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 at alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmwar
>>> e
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>