Skip to content

Conversation

@marcinszkudlinski
Copy link
Contributor

No description provided.

Currently bind api call passes IPC4 header
only. This commit extends API by adding
pointers to sink/source of the entity that is
being bound.
Note that in pipeline 2.0 there's a possibility
to bind a module to a module, therefore pointers
to sink/src need to be provided instead of
a pointer to a buffer

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Currently unbind api call passes IPC4 header
only. This commit extends API by adding
pointers to sink/source of the entity that is
being bound.
Note that in pipeline 2.0 there's a possibility
to bind a module to a module, therefore pointers
to sink/src need to be provided instead of
a pointer to a buffer

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
This commit adds bind/unbind hook to sink/source API
It is guaranteed that the hooks will be called on
core that the API will be / was used on, what makes
them a perfect place for cache operations needed at
start/end of usage.
Note that free method is not a good place for this, as
in case of shared buffers it may happen on either of
the cores the buffer connects

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Unbind used to be ignored for components in the same pipeline
But there are some code that depends on the event and
need to have it in all situations, i.e. dai_zephyr_unbind
or cross-core DP connections in the same pipeline

Propagate the event in all cases

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
unbind hook in buffer is guaranteed to be called on the
core that was using the API. Free, however, may be
called on other core

Add cache invalidation, that must be called on core that
was producing data (user of sink API) in unbind hook.

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
struct vmh_heap is a private structure and should not
be used outside of regions_mm.c file

structure moved

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
In case of cross core buffers a buffer may be allocated
and freed by different core, depending on which
component is deleted second.
As all control structures of virtual heaps are
stored in uncached aliases, there's no technical
problems with allowing virtual heaps to work cross
core.
The only consideration is that in case of cross core
allocate/free the cache invalidation MUST be performed
on the core that was storing data. It is up to the
memory user to ensure this

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
virtual heap may be called from multiple threads,
all operations should be protected my mutex
Spinlock used as race here is not very likely

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
struct sof_audio_buffer is a "base class" in
a meaning of C++ of all buffers in SOF (currently
comp_buffer and ring_buffer). Freeing of memory was
based on indirect assumption that struct sof_audio_buffer
is a very first field of the buffer structure

this commit moves freeing of buffer to a method
specific for each buffer type, enforcing that proper
pointer will be used regardless of buffer structure

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant