The topology file currently provides information on which
pipeline/processing is to be scheduled on which DSP core.
To help diagnose potential issues, this patch provides an override of
the 'core' tokens to use the primary core (typically core0). Of course
this may result in a Core0 activity that exceeds hardware
capabilities, so this should only be used when the total processing
fits on DSP - possibly using firmware mockup processing and stubs.
No new dmesg log was added to avoid adding noise during topology
parsing, but the existing logs will show the primary core being used.
This is strictly for validation/debug, products should NEVER use this
override, the topology is assumed to be the description of the
firmware graph.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20211006110645.26679-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
#define SOF_DBG_DYNAMIC_PIPELINES_ENABLE BIT(4) /* 0: use static pipelines
* 1: use dynamic pipelines
*/
+#define SOF_DBG_DISABLE_MULTICORE BIT(5) /* schedule all pipelines/widgets
+ * on primary core
+ */
#define SOF_DBG_DUMP_REGS BIT(0)
#define SOF_DBG_DUMP_MBOX BIT(1)
goto err;
}
+ if (sof_core_debug & SOF_DBG_DISABLE_MULTICORE)
+ pipeline->core = SOF_DSP_PRIMARY_CORE;
+
if (sof_core_debug & SOF_DBG_DYNAMIC_PIPELINES_OVERRIDE)
swidget->dynamic_pipeline_widget = sof_core_debug &
SOF_DBG_DYNAMIC_PIPELINES_ENABLE;
return ret;
}
+ if (sof_core_debug & SOF_DBG_DISABLE_MULTICORE)
+ comp.core = SOF_DSP_PRIMARY_CORE;
+
swidget->core = comp.core;
ret = sof_parse_tokens(scomp, &swidget->comp_ext, comp_ext_tokens,