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}, ..... };
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.
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.
Liam