On Tue, 2018-05-08 at 13:36 +0800, yanwang wrote:
On Mon, 2018-05-07 at 17:16 +0300, Seppo Ingalsuo wrote:
On 07.05.2018 14:20, Liam Girdwood wrote:
On Fri, 2018-05-04 at 18:01 +0300, Seppo Ingalsuo wrote:
Signed-off-by: Seppo Ingalsuo seppo.ingalsuo@linux.intel.com
src/include/sof/trace.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/include/sof/trace.h b/src/include/sof/trace.h index 5409a1f..2fd77fe 100644 --- a/src/include/sof/trace.h +++ b/src/include/sof/trace.h @@ -71,7 +71,7 @@ #define TRACE_BOOT_PLATFORM_IPC (TRACE_BOOT_PLAT FORM + 0x170) #define TRACE_BOOT_PLATFORM_DMA (TRACE_BOOT_PLAT FORM + 0x180) #define TRACE_BOOT_PLATFORM_SSP (TRACE_BOOT_PLAT FORM + 0x190)
+#define TRACE_BOOT_PLATFORM_DMIC (TRACE_BOOT_PLATFORM + 0x1a0)
/* trace event classes - high 8 bits*/ #define TRACE_CLASS_IRQ (1 << 24) @@ -95,6 +95,7 @@ #define TRACE_CLASS_EQ_FIR (19 << 24) #define TRACE_CLASS_EQ_IIR (20 << 24) #define TRACE_CLASS_SA (21 << 24) +#define TRACE_CLASS_DMIC (22 << 24)
oh, we should really export trace types to a uapi header (trace.h ?) that rmbox can include.
Should I do a generic patch for all TRACE_CLASS first (without DMIC stuff)? And should the TRACE_BOOT definitions be there too?
I am seperating trace into global, comp_dev, comp_buffer and piepeline trace. Could it be changed after trace level patch set merged? Thanks.
Yes, lets merge this first and then see what we have to do stringwise. We do have more bits in the trace format now too (i.e. we could include the comp ID in trace data).
If comp ID is in trace data then rmbox could read the component names & IDs from debugFS to match names with IDs so we could print the actual topology component name next to the trace message. This would need a patch to the driver to create a debugFS file for each component that could list it's properties (like ASoc DAPM widgets already have).
Liam