Repository navigation
Conversation
17a19b2 to
f61ffb7
Compare
bind/unbind handler must be called from core on which component was created. When both source and sink components are created on same core, bind/unbind IPC is processed on that core. However, when connected source and sink are on different cores, IPC is processed on core 0. Hence comp_bind_remote() and comp_unbide_remote() is added to call bind/unbide from proper core. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
To support pipelines connection between cores, ipc4_create_buffer() must be able to create buffer shared between source and sink components created on different cores. ipc4_create_buffer() requires source component obs size. When both source and sink components created on same core, ipc4_create_buffer() is executed on that core, otherwise it is executed of core 0 (IPC processing core). So for the case when source and sink components are created on different cores comp_get_attribute_remote() is used to receive source obs size. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Pipeline data is allocated in cached space. This workaround prevents from accessing another core pipeline data when calculating latency. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
f61ffb7 to
272880d
Compare
|
Good direction: a module MUST be used exclusively on one core - from creation to destruction. That includes data copying and all setup callbacks etc. cross core / cache operations should be executed by pipeline/sink/src/etc. code |
There was a problem hiding this comment.
Both comp_bind() and comp_get_attribute(), called from ipc4_create_buffer() are called from ipc_comp_connect() which has
Lines 375 to 376 in 95874fd
Consider the case of two connected pipelines, one on core 1 and another on core 2. In such case we cannot simply pass IPC to core 1 or core 2, instead IPC is still processed on core 0 and bind() is called on core 1 for one of the components and on core 2 for another. Current implementation (before this PR) only supports a case when both connected components are on same core, but, we, seems, have to support a cross core connection of pipelines. |
Ah, the |
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
Looks good @serhiy-katsyuba-intel, I guess also needs more validation before merge ready ?
| static inline int comp_get_attribute(struct comp_dev *dev, uint32_t type, | ||
| void *value) | ||
| { | ||
| #if CONFIG_IPC_MAJOR_4 |
There was a problem hiding this comment.
better to have two copies of comp_get_attribute, 1 for ipc3 and the other for ipc4 (and this way we can put the ipc4 version with all the other ipc4 code in teh header under a single ifdef).
4 participants
Set of fixes to support connected pipelines created on different cores. We need cross core connected pipelines support as part of DP scheduling implementation.
Additionally, this PR #7962 is required to support multi pipeline set state IPC when pipelines are created on different cores.