New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SOF: Multicore support failed when _widget_free introduced. #2824
Comments
@keyonjie with all due respect, this is a terrible bug description... Can you please reword it with code pointers so that we don't have to reverse-engineer your line of thought, or why it's TGL-specific, and whether this is for dynamic pipelines or not. |
Thanks for feedback, only had 3 minutes to heads up this on github last night, now revised. |
@keyonjie I agree we should power off cores properly depending on refcount with multicore. But we must be missing something in our suspend sequence too. We must not be updating the enabled cores mask when poering up secondary cores via IPC. Something to look into |
It looks to me that the powering up of the secondary cores works fine (the enabled cores mask set correctly), but the widget free or runtime suspending not clearing this mask for us. Sorry I assigned this to you as I think you know this part best. |
@plbossart since @ranj063 is in leave, I may take my old PR #888 back to address this issue. |
Hi @plbossart @ranj063 I managed to figure out solution for this in my PR #2850, please help to review. |
This is impacting a key feature in sof-dev, so applying P1. |
The recent changes to use common code to power up/down DSP cores also removed initialization of core status at suspend. It turns this is still needed. BugLink: thesofproject#2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: thesofproject#2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: #2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: #2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Yes, let's close it, and file new multi-core issues if observed by CI after topology change thesofproject/sof#4153 merged. |
The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: #2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: #2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: #2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: thesofproject#2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: thesofproject#2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20210528144330.2551-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
commit b640e8a upstream. The recent changes to use common code to power up/down DSP cores also removed the reset of the core state at suspend. It turns out this is still needed. When the firmware state is reset to SOF_FW_BOOT_NOT_STARTED, also enabled_cores should be reset, and existing DSP drivers depend on this. BugLink: thesofproject/linux#2824 Fixes: 42077f0 ("ASoC: SOF: update dsp core power status in common APIs") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20210528144330.2551-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We call sof_pipeline_core_enable() in sof_widget_setup() to power up the corresponding DSP cores,
linux/sound/soc/sof/sof-audio.c
Line 160 in 9f92f3c
but not do the corresponding powering off Cores at sof_widget_free(), e.g. at runtime suspending,
linux/sound/soc/sof/sof-audio.c
Line 94 in 9f92f3c
this will lead to the subsequent run of the pipeline/widget after the runtime suspend/resume cycle on non-0 DSP core fail as the driver will keep think core 1 is already enabled according to the sdev->enabled_cores_mask,
which is not aligned with the FW side, the FW will complain with "ipc_process_on_core(): core 1 is disable" and reject to run it.
https://github.com/thesofproject/sof/blob/0b0733749c55b39c9e8699538b77c65f0c322397/src/ipc/ipc-common.c#L44
This is actually SOF common issue, not TGL specific, and happen in all scenarios where widgets free is used, including runtime suspend/resume, not dedicated for dynamic pipelines only.
Proposed solution:
add refcount to each DSP core, increase/decrease the refcount when a widget/pipeline using the Core is created/freed, and do the core power up/down and core enable/disable IPC only when needed.
The text was updated successfully, but these errors were encountered: