[Sound-open-firmware] [PATCH] [RFC]rmbox: include trace class definitions from trace header

Yan Wang yan.wang at linux.intel.com
Sat May 19 08:23:43 CEST 2018



On 5/19/2018 4:01 AM, Liam Girdwood wrote:
> On Fri, 2018-05-18 at 22:24 +0800, sound-open-firmware-bounces at alsa-project.org
> wrote:
>>>
>>>
>>> So these are non component trace class IDs now, they dont need to be in
>>> ipc.h
>>> and should start at some high number so they wont conflict with component
>>> IDs
>>> (that start at 0).
>>
>> Yes. I will keep current class << 24 for global trace.
> 
> No, ditch this. Just use a single ID with IDs > 0xffff0000 for non components.

Sure. I can do it.

> 
>> For component id,
>> it will be restored in another unused uint32 bit currently. So they will
>> not cause conflicts.
>>
>>>
>>>> 938 /* DMA for Trace level elem - SOF_IPC_DEBUG_DMA_LEVELS */
>>>> 939 struct sof_ipc_dma_trace_level {
>>>> 940         uint32_t trace_class;
>>>> 941         enum sof_dma_trace_level_type type;
>>>> 942         int32_t comp_id;
>>>> 943         char name[8];
>>>> 944         uint32_t level;
>>>> 945 }  __attribute__((packed));
>>>
>>>
>>> All you need here is name and ID. level, type will be set by userspace.
>>
>> May we need one default level for this? I also want use comp_id to
>> identify global and component trace level. If comp_id = -1, it is global
>> trace level.
> 
> No, comp_id is the ID of the target (component or class). No need for global
> level.

Sure. I can do it.
Thanks.

Yan Wang

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


More information about the Sound-open-firmware mailing list