[Sound-open-firmware] [PATCH] [RFC]rmbox: include trace class definitions from trace header
yanwang
yan.wang at linux.intel.com
Fri May 18 10:52:28 CEST 2018
On Fri, 2018-05-18 at 09:06 +0100, Liam Girdwood wrote:
> On Fri, 2018-05-18 at 10:09 +0800, Yan Wang wrote:
> >
> > >
> > > So the trace class strings are deprecated, Yan was going to
> > > export all the
> > > trace
> > > object names + IDs via debugfs (like DAPM widgets already do).
> > > rmbox should
> > > read
> > > these at startup so it could then lookup comp name from the ID
> > > number
> > > embedded
> > > in trace data.
> > >
> > > Yan, do you have parts of this implemented ?
> >
> > In my previous RFC v2 patch set, I still keep trace class macro
> > definition in trace record but support switch on/off based
> > component id.
> > I am working on displaying compoent/widget name in rmbox and will
> > submit
> > in the next version patch set.
> > But for global trace like DMA/IPC/... or early component trace
> > which
> > locates in comp_new()/pipe_new()/buffer_new() may still need trace
> > class
> > because they haven't corresponding component/widget name?
>
> Non component trace classes can be exported as "extended boot data"
> i.e.
>
> 1) create a structure array that can be appended onto the boot
> complete message
> (after SRAM windows) and sent to the host.
>
> struct ipc_trace_class_elem {
> char name[SIZE];
> uint32_t id;
> };
>
> struct ipc_trace_class {
> int num_elems;
> struct ipc_trace_class_elem[0];
> };
>
> so you would have
>
> struct ipc_trace_class_elem trace_class_elems[] = {
> {"pipeline", PIPELINE_TRACE_ID},
> .....
> };
Yes. I have finished this step now. And I also send name string from
SOF side to kernel driver.
>
> 2) The driver will create a debugFS file for each trace class elem.
> When read
> (by rmbox or cat) it will contain the ID number. This way rmbox can
> map IDs to
> names for classes too.
I think we may not need so many debugfs interfaces. We can pass one
parameter into one trace_level debugfs interface get all trace class
map. And rmbox can understand trace class after getting this map.
>
> 3) rmbox reads these debugFS files at strartup to create it's ID ->
> name
> mapings.
>
> Steps 2 & 3 are very similar to the component ID name lookups.
>
> Doing this means rmbox and the driver do not need to be modified when
> we add new
> trace objects in the FW.
Agree. We can remove all trace class macro definition.
both rmbox and kernel driver will be dependent on SOF. So it is
scalable fully.
I attach my finished structure decalation for reviwing in the
following. It still include trace class. I can remove it in the next
version patch set.
922 /* DMA trace level type */
923 enum sof_dma_trace_level_type {
924 SOF_DMA_TRACE_LEVEL_IRQ = 0,
925 SOF_DMA_TRACE_LEVEL_IPC,
926 SOF_DMA_TRACE_LEVEL_DMA,
927 SOF_DMA_TRACE_LEVEL_SSP,
928 SOF_DMA_TRACE_LEVEL_WAIT,
929 SOF_DMA_TRACE_LEVEL_LOCK,
930 SOF_DMA_TRACE_LEVEL_MEM,
931 SOF_DMA_TRACE_LEVEL_SA,
932 SOF_DMA_TRACE_LEVEL_DMIC,
933 SOF_DMA_TRACE_LEVEL_SCH,
934 SOF_DMA_TRACE_LEVEL_VALUE,
935 SOF_DMA_TRACE_LEVEL_END,
936 };
937
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));
946
947 /* DMA for Trace level info - SOF_IPC_DEBUG_DMA_LEVELS */
948 struct sof_ipc_dma_trace_levels {
949 struct sof_ipc_ext_data_hdr ext_hdr;
950 uint32_t num_levels;
951 struct sof_ipc_dma_trace_level level[0];
952 } __attribute__((packed));
We can also use this structure to set and query multiply module/class
trace levels.
My current focus issue is component/widget trace level list from SOF
side. When FW_READY message sent, the topology should not be loadded.
I may have to send component/widget trace level list later. Is it
right?
Thanks.
Yan Wang
>
> Liam
More information about the Sound-open-firmware
mailing list