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
Fixes for dynamic pipelines and multi-core #3019
Fixes for dynamic pipelines and multi-core #3019
Conversation
82f7381
to
a6225cd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is somewhat challenging set to review, but the changes seem correct. The main concern I have are the new ops. It seems a get/put model is the way to go, but now that we introduce it, having the old power_up/down ops seem really out-of-place.
9bfcc3f
to
3f1488f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think this API makes more sense than the previous one, looks nice! Just some minor clean up. Since none of the comments address real bugs, I'll make it a comment
|
||
/* reset route setup status for all routes that contain this widget */ | ||
sof_reset_route_setup_status(sdev, swidget); | ||
swidget->complete = 0; | ||
dev_dbg(sdev->dev, "widget %s freed\n", swidget->widget->name); | ||
|
||
return 0; | ||
return ret; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can return a negative error code if the IPC failed but in fact you still performed the rest of the clean up. A failing IPC used to return an error from this before too, so you aren't changing that. There are many places in hda.c and hda-dai.c where this error code is propagated to the caller, hopefully they're all correct and are taking into account that this can be a "soft" failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, the thing is the core ref_count needs to decremented even if the widget free fails. I think this is correct to do a core_put even if widget free failed. Otherwise, the core ref_count's will be messed up and will prevent D3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove my request-changes for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove SSP and SoundWire patches from this PR, they are controversial and need to be tested separately.
Add two fields num_cores and dsp_cores_ref_count to struct snd_sof_dev. These will be used to maintain the ref count for each core to determine when it should be powered up or down. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Add ops to get/put a core that will be used to power up/down a core along with incrementing/decrementing its ref_count. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Set core_get/put() ops for TGL. When core_get() is requested for a core, its ref_count is incremented and the PM_CORE_ENABLE IPC sent to the firmware to power up the core if the current ref_count is 1. Conversely, the ref_count is decremented in core_put() and an IPC is sent to the DSP to power off the core if the ref_count is 0. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
716ff58
to
fe4f2a9
Compare
fe4f2a9
to
64abd7d
Compare
@plbossart @lyakh do you have any more comments/concerns with this PR? |
Set core_get/put ops for CNL/ICL platforms. These platforms do not support enabling/disabling secondary cores dynamically. So skip sending the IPC to power off the cores in the core_put op. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Remove the function sof_load_pipeline_ipc() and directly send the IPC instead. The pipeline core is already enabled with the call to sof_pipeline_core_enable() in sof_widget_setup(). Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
…ines Free widgets for static pipelines in sof_tear_down_pipelines(). But this feature is unavailable in older firmware with ABI < 3.19. Just reset widget use_count's for this case. This would ensure that the secondary cores enabled required for topology setup are powered down properly before the primary core is powered off during system suspend. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
The core_power_up/down() ops will be deprecated. Use the HDA platform-specific functions for powering up/down the cores during probe/suspend/remove. The enabled_cores_mask and the core ref_count's are manually updated in each of these functions. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
This patch adds support for dynamic pipelines with multi-core by using the platform-specific core_get/put() ops to power up/down a core when a widget is set up/freed. Along with this, a few redundant functions are removed: 1. sof_pipeline_core_enable() is no longer needed as the pipeline core will be set up when the pipeline widget is set up 2. sof_core_enable() is replaced with snd_sof_core_get() 4. core_power_up/down() DSP ops are deprecated and replaced with core get/put ops. 5. Core power down in sof_widget_unload() during topology removal is also removed as it is not really needed. For dynamic pipelines, the cores will be powered off when they are not used. For static pipelines, the cores will be powered off in the device remove callback. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
To keep the widget use_counts balanced, free the DAI widget during suspend and also during the stop trigger. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
64abd7d
to
8587c32
Compare
There is no regression found when I run run-all-tests.sh on my CML device. |
I started Intel test 5682 on this PR as the last verification prior to merge. |
test 5682 did not show any new issues, let's merge. |
No description provided.