[ranj063]

There's no reason for buffers to be left on core 0
when the rest of the pipeline in on a different core
unless absolutely required.

Signed-off-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com

[ranj063]

SOFCI TEST

[lyakh]

what does this mean in practical terms - was something executing on the default core instead of the selected secondary core before this commit?

[lgirdwood]

TGL-H showing a PM timeout but nothing in the logs except a keyboard error - rerun again to be sure.
https://sof-ci.01.org/sofpr/PR4705/build10178/devicetest/?model=TGLH_RVP_HDA&testcase=check-suspend-resume-with-capture

[lgirdwood]

SOFCI TEST

[ranj063]

@lgirdwood is this one good for merging? CI failure on helios is a device issue I think

[plbossart]

what does this mean in practical terms - was something executing on the default core instead of the selected secondary core before this commit?

@ranj063 can you address @lyakh 's comment?

[ranj063]

what does this mean in practical terms - was something executing on the default core instead of the selected secondary core before this commit?

Yes, so if you have a pipeline host->buffer->pga->buffer->dai, the host/pga/dai components would get scheduled on Core X as selected in topology but the 2 buffers were left on core 0 by default.

[lgirdwood]

SOFCI TEST

[lgirdwood]

Hopefully CML DUT is UP this time.

[lyakh]

what does this mean in practical terms - was something executing on the default core instead of the selected secondary core before this commit?

Yes, so if you have a pipeline host->buffer->pga->buffer->dai, the host/pga/dai components would get scheduled on Core X as selected in topology but the 2 buffers were left on core 0 by default.

@ranj063 yes, thanks, but what exactly does that mean? As far as I understand buffers aren't active components, they don't have tasks. Which code wrongly gets to run on the primary core currently?

[ranj063]

what does this mean in practical terms - was something executing on the default core instead of the selected secondary core before this commit?

Yes, so if you have a pipeline host->buffer->pga->buffer->dai, the host/pga/dai components would get scheduled on Core X as selected in topology but the 2 buffers were left on core 0 by default.

@ranj063 yes, thanks, but what exactly does that mean? As far as I understand buffers aren't active components, they don't have tasks. Which code wrongly gets to run on the primary core currently?

today we check the buffer's core to decide whether it is shared or not. Ideally we should check if the source/sink components are on different cores. I will be changing this logic soon

[lgirdwood]

@ranj063 btw, just thinking if we need this now if we are going to mark the shared state at runtime based on source and sink ? We could deprecate buffer->core ?

[ranj063]

@ranj063 btw, just thinking if we need this now if we are going to mark the shared state at runtime based on source and sink ? We could deprecate buffer->core ?

@lgirdwood yes, lets hold off on merging this and I will submit the other PR soon.

[ranj063]

with the changes in #4739, this PR is no longer needed.